That's about what I was thinking, too. It might be good to explicitly say that they would have a lot of influence over the product, so it would ideally be well-suited to their needs. And, they would have special privileges/discounts/whatever, when it hits the market. What do people think about extending/stating those kinds of things, or does that set expectations too high?
Yeah, serving up two versions simultaneously and split testing them would be more scientific, but I appreciate the number anyway. It was an after the fact observation rather than an original goal, so I wouldn't expect him to go back and deploy the slower version just to test the number.
The hole here is whether or not they unknowingly got a new influx of traffic that was 5% more likely to convert, skewing his final observation, which I would say is unlikely. Your point is good in general, however.
FWIW, I really appreciated the post, Joel. I'm actually in the process of buying a lot of this stuff for myself due to accepting a new telecommuting job. I need to furnish my home office, and as understanding as my wife is, it's hard to explain to her why this costs what it does. I probably won't spend what you do at FogCreek, but it at least relieved me of the feeling that I was misspending our money. (My tentative stack for those that care: MacBook Air, Thunderbolt Display, GeekDesk, and ? for chair)
FogBogz calls this Evidence-Based Scheduling. They take past estimates along with data on the actual time taken for past tasks and use that to predict the time required for future tasks. Caveat: I have never used it and therefore cannot vouch for how well it works. The technique appears sound.
All of these arguments are the same arguments you need to think through when determining whether to make a web app vs. a native app on the desktop. They're identical, because the desktop is just another device.
I completely agree with all the arguments, except possibly that we should never use hacks. We used (and still use) hacks on the web for desktop use when browsers sucked, and we'll do it on mobile devices, too. It's the way the state-of-the-art is pushed forward; it's inevitable. I think he would agree with me, seeing that he pointed out Scrollability's use on the iPad being somewhat valid. That said, the author's underlying point examines why we use those hacks and to evaluate whether we're solving a non-existent problem.
Edit: I might clarify my hacks point. The reason they're inevitable is that they sometimes expose browser deficiencies. A current example would be web sockets. We've been using comet-type hacks in lieu of a real web socket solution (and Chrome has now implemented one).
Agreed. The minute you know the feature does have traction and won't go away any time soon is the minute you clean or rewrite that code.
This may be semantics at some level, but I think it's important to not imply you just don't care about the quality of your code. Prototyping intentionally sacrifices some quality to prove a point quickly, but once the point is proven, you throw it away and rewrite with your normal, high standards.
In addition to the argument for keeping your styles together, CSS is declarative while Javascript is imperative. There are just less moving parts in CSS, and the browser keeps track of any "state" that you would be tracking in Javascript.
[1] http://en.wikipedia.org/wiki/Arc_(programming_language)