Hacker News new | comments | show | ask | jobs | submit login

maybe i'm getting trolled here :) but i don't see how joel's background makes his points less relevant: - it's easier to fix problems on sketches/paper than in code weeks later - specs cut down on amount of communication needed -- especially with outside stakeholders - and help with schedule estimates, etc.

sure, in your typical web 2.0 app, many things are easy to re-work, but others (e.g. end-to-end unicode support/other i18n issues, scaling, schema design, etc.) are better baked in from the beginning (just ask friendster.) or at least be cognizant of the tradeoffs you're making and budget time to throw away your prototype.

also, google and ms have pretty rigorous software engineering processes and tools (hell, they hired GvR just to write a code review tool.) sure, in the early days it was probably looser. but not zero structure whatsoever -- the total free-for-all that "just do it" implies -- hell, even "release early and often" is a kind of software engineering discipline.

there are benefits to cutting corners (i.e. the zero planning implied by "just do it") like getting to market faster for certain kinds of startups (early market feedback, etc.) but these come at a cost later on! i like dharmesh shah's idea of 'technology debt':


and your assertion that QA is something that happens only after a product already exists is equally misguided -- you can save a lot of time overall by thinking early about how to structure and instrument your code to make it easy to test.

if your response is 'well of COURSE you'd think about all these things up front', then that's not really 'just do it', is it :)

I have some experience with this. My business is http://linebuzz.com/ We wrote the first line of code on April 1 and launched on May 10. We were covered as dot-com of the day on 100shiki.com in Japan and within days we had users in 15 languages on the site with no I18N support out the door.


3 weeks later we launched an I18N release. Our customers stuck through the whole thing and worked closely with us to make LineBuzz work in their languages and charsets. Here's the story if you're interested:


Many of the I18N issues we solved we only discovered because we had a large group of international users working with us. Things like the shift_jis character set not round-trip mapping to unicode. Not the sort of thing you can anticipate on paper.

If I had to do it again, I'd do it exactly the same way. Next time we may discover that the app is only used by english users and the urgent need is to fix some privacy issues.

Most companies that plan everything out on paper tend to have a large number of non-technical folks. MBA's and the like. When you're building a consumer web business, your business plan is expressed as a piece of technology. So why not just create the technology instead of talking about it. And instead of using english to describe your business, use Ruby or Perl or PHP or Java.

Mark. ps: Sorry you feel you're getting trolled.

Joel isn't an advocate of "plan everything out on paper." It's more about discipline and attacking a problem as effectively as possible.

It's true that his advice does tend towards shrink-wrapped software, where it's not so easy to just go in and fix something after you've had real users testing it. But what you describe is closer to what he'd call "hallway usability testing." That doesn't rule out a spec as a valuable component of the development process.

Anyway, the test for the value of a spec really shouldn't be taken after just 4 months.

You ARE getting trolled. This guy managed the development of linebuzz.com (had you heard of it? I hadn't) and knocks advice from a previous program manager of excel (software that is on nearly every computer on the planet) and owner of a successful software company for the last several. You may hate Microsoft's marketing, but the fact of the matter is that in the early 90's they had great software teams filled with world class programmers. The linebuzz guy is knocking THEIR boss who led what is arguably one of Microsoft's best products.

LOL, I love guys like Joel Spolsky-- self anointed gurus handing out really terribly advice to uncritical lemmings.... this reduces competition in the marketplace for those of us who think (and have experience.)

Joel is like one of those infamous Lieutenants in Vietnam-- all book learning and zero experience getting people killed-- usually to get fragged by one of their own. Since fragging is uncommon in cubicle farms, Joel still lives.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact