A bunch of cunts, mostly in the Australian sense. Except that one guy.

joels "painless software schedules"

great article.

trouble is, it's hopelessly naive.

Let's say, today we have a proof of concept of some product. We think that, given a fair amount of work and a number of new features, it'd be a product.

so we have to:
- define the features
- prototype them
- do UI testing
- do market testing
- implement features
- deploy

In some cases, if you are dealing with the seeding stage of a startup, you don't even know *who* will be doing some of those tasks. You may have some contractors or possible hires in mind. You probably can't at this stage have a detailed discussion and estimate of each fine grained task. You'll be lucky if you can identify them at the level Joel suggests ("write function x").

But you still need a roadmap, and a set of milestones for V1.0, 1.1 ... and you still have to *try* to estimate timescales and effort requirements.

So Joel's approach is great, and an admirable goal, but in many real world situations, you can't actually do it.
Permalink $-- 
September 10th, 2006 12:07am
I tried the Excel method, but each time I wanted a new feature (dependancies, weekends, vacations, multiple people working on a single project, etc.) I realized that that feature was in MS Project.
Permalink wheeeeeee ~~~~~~~~~~x 
September 10th, 2006 12:10am
this makes more sense to me for a large planning:

http://www.mindtools.com/pages/main/newMN_PPM.htm

gantt charts and stuff may be soooo 1990, but when the shit is big and complex ...
Permalink $-- 
September 10th, 2006 1:01am
MS Project isn't great for software, because MS Project is designed for repeatable tasks, and there are almost never repeatable tasks in software development.

I would even venture to say MS Project is no good at all for small teams, because the overhead and inaccuracy pretty much invalidate it.

There's a continuum - at one end is "Just start writing code". At the other end is "plan everything out and eliminate any risk whatsoever in writing the software"

The problem with the "plan everything" end is that to truly identify and eliminate every single risk, you end up writing the software.

Joel tries to force a project manager to identify points of potential risk without suggesting you can eliminate all risk. IOW - "this is about as detailed as you want to get; any more detailed and you should be coding"
Permalink Send private email Philo 
September 10th, 2006 1:02am
the article I pointed to says this too. For small/medium stuff, you can do it with task lists and a calendar.

but if you have something bigger, you are gonna have to start making rough estimates for stuff that is a long way off, and you know already that that will change as you get closer. Nothing much you can do, it's tough, but not doing it at all is way tougher.

I *never* liked MS Project. excel is good for task lists though.
Permalink $-- 
September 10th, 2006 1:05am
"The problem with the "plan everything" end is that to truly identify and eliminate every single risk, you end up writing the software."

When you're paying Project Managers $100k a year, and they have to make MS Projects that feed into larger, master MS Projects where your project has 3 or 4 dependancies, and other projects depend on yours... you tend to get anal about these things, even though programming isn't like brick building, you end up telling them that you can lay about half a wall a day.
Permalink wheee ~~~~~~~~~x 
September 10th, 2006 3:30am

This topic is archived. No further replies will be accepted.

Other topics: September, 2006 Other topics: September, 2006 Recent topics Recent topics