Re:Joel: Five Easy Ways to Fail (in a Software Project)
by mdemare on Thursday October 25, 2007 @12:08PM
(#72545)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by hello_moto on Thursday October 25, 2007 @01:08PM
(#72575)
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).
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by brlewis on Thursday October 25, 2007 @01:31PM
(#72584)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by bootload on Friday October 26, 2007 @01:02AM
(#72807)
"... 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:
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by breck on Thursday October 25, 2007 @12:27PM
(#72556)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by jgrahamc on Thursday October 25, 2007 @12:18PM
(#72553)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by brianr on Thursday October 25, 2007 @12:44PM
(#72561)
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'.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by olavk on Thursday October 25, 2007 @03:57PM
(#72637)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by ph0rque on Thursday October 25, 2007 @04:14PM
(#72644)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by MuddyMo on Thursday October 25, 2007 @03:41PM
(#72631)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by michaelneale on Thursday October 25, 2007 @08:52PM
(#72745)
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).
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by euccastro on Thursday October 25, 2007 @03:04PM
(#72618)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by rontr on Friday October 26, 2007 @12:56AM
(#72805)
"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'!"
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by michaelneale on Thursday October 25, 2007 @06:05PM
(#72692)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by edw519 on Thursday October 25, 2007 @12:05PM
(#72544)
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.
Re:Joel: Five Easy Ways to Fail (in a Software Project)
by dshah on Friday October 26, 2007 @12:37AM
(#72797)
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.
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.
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).
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.
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.
John.
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'.
Not sure he would qualify as one of those (not even sure what the definition is).
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.
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.
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.
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.