Joel: Five Easy Ways to Fail (in a Software Project) | Hacker News Reader

Joel: Five Easy Ways to Fail (in a Software Project)

inc.com

51 pointsluccastera31 comments

I love Joel for promoting the idea that working more than 40 hours a week is unproductive, but it does seem contrary to the startup mentality.

Would startups be better off if their founders only worked 40 hours a week? I don't think so - working crazy hours is a competitive advantage of startups.

Of course, motivation is the big difference, but that's a whole different argument than Joel is making.

My experience is that you should _plan_ as if you have 40 hours a week per developer because you are going to be wrong and end up needing more time than you expect. The work after 40 hours is just keeping you on schedule.

John.

That seems a bit counterproductive to me--if you know it's going to take more than 40 hours, then why not at least try to make an estimate? If you think that your weeks' work is going to take between 50-70 hours, then budget 70 hours and be glad (or get ahead!) if you finish early.

That said, I can't imagine any startup getting far by working 40 hours a week. 80-100 is probably a minimum for a founder... it has to be your focus, not just your 'day job'.

I wonder if anyone have actually done the experiment? When you are doing a startup, you want to work as much as possible, however it might very well be that you would be just as productive if you worked just 40 hours.

I'd be very interested in seeing such a study. I think the answer lies in not just how hard you work, but how smart you work; i.e. monitoring your productivity and adjusting various factors (length of time, time of day, etc.) to maximize productivity.

If you're doing a startup, your life will be the startup. It won't seem like work. But if you hire employees, their life will not be the startup. And it will still be more "work-like" to them than it is to you. So keep them to 40 hours.

Joel's experience working for Microsoft shaped his mind. It has been MS trademark to start slow but building a _SURE_ thing with good architecture (security is a different story).

How old is MS Office now?

Compare that with Silicon Valley startup mentality: code like crazy, take shortcuts, release early, flipped your company and let the new hires figured out the mess.

(Or you could opt for re-writes like the Reddit people have been doing since their inception).

Also startups are short bursts relatively speaking, coding binges etc. He is talking about something sustainable for a career (of sorts).

Do you know anything about the early history of Microsoft?

Was Joel working for Microsoft during its early history?

Yes. He was responsible for VBA in Excel, amongst other things.

I think spending more than 40 hours per week programming is unproductive, because of the mental exertion, but there's a lot more to launching a successful startup than programming.

Once you've expanded to the point where you have people who only program, Joel's advice is probably good: "encourage your staff to work a sane 40 hours per week" except for occasional bursts.

I find switching between programming and "business" tasks even harder than programming for many hours straight.

Me too. I'm much more productive when I can focus on just one kind of task.

"... but it does seem contrary to the startup mentality. ..."

Joel is a pretty smart businessman and a lot of the articles are written within the management of an established software company frame of mind. Remember that:

- FogCreek is not a startup

- FogBugz has a long ship cycle

- products developed are mature

- code base is being used over a long time frame

- good software takes 10 years anyway ~ http://www.joelonsoftware.com/articles/fog0000000017.html

Quite the antithesis of what you might associate with Startups discussed here.

Joel is a rarity: brilliant, successful programmer, entrepreneur and writer. But when writing about how to develop successful software, it tends to be things that would resonate with frustrated enterprise software programmers, like he used to be, or guys like Scoble perhaps. But his theme is similar to PG's, concentrating on making it possible to develop software using programmers with average talent will not result in exceptionally useful software programs.

>enterprise software programmers, like he used to be

Not sure he would qualify as one of those (not even sure what the definition is).

Your right, for brevity's sake, I sacrificed clarity. Perhaps "programmers of software driven by large enterprise marketing departments"

Yes that would be better. But then a lot of software falls under that. That which doesn't can also be described in belittling terms. Pick any software you like, mostly it will be trivial (or possible to describe it in trivial terms).

Clearly, only superstar hackers are skilled enough to add features to FogzBugz.

Even if anyone could add features to FogBugz, not everyone can do it in a way that leaves the codebase clean enough afterwards.

It doesn't take much inherent difficulty or complexity for a project to become a total mess in a year or two if left in the hands of incompetent programmers.

"Superstar" is a word that should be reserved for a select few. For example, the hackers who built the Google search engine are superstars. I somehow doubt people of such caliber send their resumes to Fog Creek Software seeking opportunities to maintain aging enterprise bug tracking software.

This article reads to me like a thinly veiled recruitment effort. "Work for me and I'll appreciate your contribution, only ask you to work 40 hours a week, and even call you 'superstar'!"

I'd rather start a startup.

Yes, it takes brains to use Wasabi, a language that's probably roughly as powerful as the next release of Visual Basic.

This is phenomenal advice. In my experience, everything said here seems to be 100% true.

Even the fine grained estimates? Maybe if you are building software to "spec" (ie someone elses) but for actual software companies, I find it hard to believe that works well that often. Leaves no room for "discoveries". But everything else seems consistent with my experience.

One Easy Way to Fail (a Software Project)

By doing anything other than the following:

Have one to three rock stars and a pretty clear picture of what your audience wants. Code like crazy. Get Version 1.0 out there. Get feedback. Adjust. Repeat until done.

Well said.

One thing that was glaringly missing from Joel's article was the importance of taking in user feedback and iterating like crazy. I'd go so far as to say that iteration is even more important than fine-grained estimates.

at FogzBuz developers don't write software... software writes itself!!

Published November 2007 ?

He's so productive, he's constantly living in the future...

Inc. is a print magazine. This is just an online version of the offline article in a magazine that's printed a month ahead.

Reply on news.ycombinator.com