Hacker News Reader

Comment by dr_ | Hacker News Reader

"This makes it extremely difficult to evaluate products shipped in such incomplete form. "

No it doesn't. If that's what they give you, that's what you review. If x is missing, you say the product lacks x. If the manufacturer is not happy with that, then maybe they shouldn't release the product until it's fully functional.

View on HN

If anyone is hoping for Samsung to value perfection at launch over being one of the first-to-market in every Android form factor, they're holding out for a Galaxy far, far away.

But it seems to be working well (enough) for Samsung. I agree, though, that reviews should always be based on what the reviewer has in-hand. Every review I've read for non-Apple tablets has offered some "benefit of the doubt" that the iPad never got... or needed.

On the other hand...

We currently have no way of knowing how Samsung's software customizations will impact the Tab 10.1's performance, reliability, or battery life when TouchWiz eventually gets rolled out to consumers.

...don't ignore the possibility that things might get worse when the manufacturer's "enhancements" and "features" are added, and readers who go by a review of the product in its current state might be disappointed with the product they get next month.

Not including the addl ui layer and Flash is definitely going to make your battery look better.

How so vis-a-vis mobile Flash?

Doesn't it do hardware acceleration?

If that's what they give you, that's what you review. If x is missing, you say the product lacks x.

While that would be satisfying for the writer, the reader wants to know what it will be like to own one. They may buy one several months from now, and keep using it for years. The author is saying they can't evaluate the dominant experience of actual users.

Wait, are you saying that it is impossible to write a review that is useful for the reader unless it is a review of a product which is not going to change in the future?

Change is fine if it is aimed at making the overall experience better. From what we have seen in the past, any UI layer an OEM adds above stock Android just makes the overall experience worse, performance wise mainly. The reviews would never be able to foresee that.

Gruber keeps spazzing about the slant given to "incomplete" products and he does have a point.

He spazzed in the other direction when it came to the iPhone (copy/paste et al)

I'd be curious to know the longer-term traffic data for sites which do these types of reviews. Folks like us are quick to read these reviews, but I wonder how many regular users are reading them, say, four months down the road. I know when I'm researching a purchase about which my knowledge is nothing noteworthy, the immediate reviews (like this one from Ars) are beneficial to me when compared to later reviews because it enables me to see how the product has developed over time.

I think long term traffic is a major focus for them all - the products become released, they probably have great success sending people straight from reviews to vendors through advertisements - if they can secure good positions in search engines. Content farms like Engadget (Ars are much higher quality) try pretty hard to corner Google rankings for products, manufacturers and everything else.

Here's an Engadget review of the same product:

http://www.engadget.com/2011/06/08/samsung-galaxy-tab-10-1-r...

- 18 internal links to their own garbage articles and tag pages which only exist for search engines

- 20 tags that cover everything they could think of that you might put into Google: android 3.1, android tablet, Android3.1, AndroidTablet, galaxy tab, Galaxy Tab 10.1, GalaxyTab, GalaxyTab10.1, google, honeycomb, review, Samsung, Samsung Galaxy Tab 10.1, SamsungGalaxyTab10.1, slate, tab, tablet, tablet pc, TabletPc, video

- no external links that might accidentally boost someone else's SERPs

> ...then maybe they shouldn't release the product until it's fully functional.

But ... but ... but what about all the advice we keep hearing about MVPs and "ship ship ship" and "iterate" and...?

For software that the developer can update instantly (an OS update doesn't count), then yes, this is a great methodology to live by. Hardware is a completely different beast, and costs significantly more for the purchaser and should be tested to extreme levels before launching.

I've yet to be won over to the fast-iteration model of software (or product) development, mostly because I think that presenting an unfinished, or unpolished, product to a customer is usually a bad idea. Even if you get it right later, the customer is still going to be left with a poor first impression.

Apple, despite their faults, is a great example of this: the majority of their products are carefully polished and finished, with a lot of attention to detail.

Obviously a company doesn't want to sit on a new product for too long, trying to perfect it before releasing it, and obviously a company should continue to improve its products and services continuously, preferably at a nice, steady rate. But, I'm steadfastly opposed to shipping unfinished products. I think it's bad advice every time I hear it or read it, and I think the negative parts of this review are a good example of why.

I know you mentioned fast-iteration, but you also mentioned MVP in your earlier comment, so I thought I refer to that.

When Apple first released iPhone, there wasn't an SDK publicly available. There wasn't copy and paste. There was also only EDGE/GPRS support, no multitasking (of any form except for a few built-in apps), no third party apps, no MMS, no SMS forwarding, no group SMS. It was only available in the US and only for AT&T subscribers. In many sense of the term, it is an MVP and it worked. It's just an MVP that was very polished.

As it rolled out releases, there were both enhancements and spots where they aren't as polished which was improved in a later release. Push Notifications in 3.0 + the coming Notifications center in 5.0 comes to mind.

So, they did an MVP with iPhone, initial features were minimum, but a selected subset of them are extremely polished. In fact if you look at many successful iPhone apps, this seems to be a very successful model.

Perhaps this approach only works on Apple's "target market". But I'd like to think this is an excellent approach when working with mass market consumers.

This link where Steve Jobs commented about Segway's marketing and launch is not totally relevant, but still interesting - http://hbswk.hbs.edu/archive/3533.html

That advice usually means that you're better off shipping 5 awesome features not 10 crappy ones.

"ship ship ship" is hard when it comes to hardware.

As for the software side of things, I'd say "QA", but I find the dev/release cycles at these major phone/tablet manufacturers to be unbelievably slow. As in, I really don't understand what they're doing a lot of the time. 5 volunteers working on CM can fix and implement features in the time it takes Motorola's team to do a `git merge` on Android and push it out to their phones (yes, even non-Blur phones).

I wonder if a lot of what we read about software development methodology is to blame for this? I would expect that individual and freelance developers, and developers at small companies, are more likely to practice "cowboy programming" -- use frameworks, glue them together, write code, handle (most) edge cases, exercise the most basic of best practices -- while larger companies, like Motorola, are more likely to practice something that a manager read about in a book or a consultant sold them on -- "waterfall development", "test-driven development", etc.

(Not that I have anything against those methods, but they would tend to slow down development in a corporate environment.)

I'm not sure it's so cut and dry. If you look at how CM releases are managed... they're very well done. Nightly build servers, good communication on their GitHub and Gerrit, very stable builds considering their nightly builds, all the dozens of phones exist as the larger CM project. I know you were speaking more generally, but I don't know that one or the other is always better, whether it's speed or style or development workflow.

Reply on news.ycombinator.com