The Modified Pareto rule for software projects:
When you are 80% done, you will spend 80% of the time used up until this point, on the remaining 20%.
This is a recursive rule, so you will actually never be done - although you probably will get to a point where you consider yourself close enough to done to actually ship.
Trouble is, you have to maintain the list, adding on all the things that you didn’t think you hadn’t thought of.
It might well be that new stuff comes up, that has to be added. I find it has a tendency to add about 10% to the overall estimate.
One day, I’ll get myself and my users well-enough organised to be able to use stories and iterations (like XP) or sprints (Scrum) or something similar.
One day.
Yeah, let’s map out all the features and break each feature down into tasks. Whack that into a plan and what do we have? Waterfall!
The real problem is that software development quite often involves invention. As Cockburn puts it: A cooperative game of communication and invention.
Often, the only way we know everything we need to do is to actually do it.
Not wishing to label everyone the same way, I think the dislike of lists and scheduling is fairly usual with software developers.
This might just be down to the idea of If I could write down everything it needed to do then I’d have done it already!
The advantage of Software as a Service is that a 90% complete solution can often be put live with the last 10% being mopped up as required.
This ties in well with a developers dislike of lists as the 90% list is a lot easier to produce. Ask for a list of everything needed to be done in order to go live and everything needed to be done to be complete and one will happen a lot quicker than the other.
As long as everyone at all stages is well prepared for this 90% mentality then it’s actually a good morale and performance boost. It usually falls into the possible side of things rather than the impossible.
Then when it comes to hitting the final 10% as a separate entity it also now falls into the possible side of things.
It’s a Divide and Conquer mechanism for software development that I’ve always found extremely productive and nice to work with!
Robin Day
http://www.advorto.com
If you do want to create a list, make sure you know what ‘done’ means for each item. If not, your list is just as useless as not having such such list. Worse, you’ve tricked yourself that you have such a list.
I am really tired of seeing such useless list from project managers …
I find one way to have a better idea of how finished I am is to try to completely finish a task before I move on to the next one (or finish it as much as I can before I need to wait for something). I remember feeling blind panic when I was working on something once and I’d done all the major work but none of finishing up and had no idea where I was in relation to the Gantt chart I’d drawn up with my manager at the beginning.
lists are good but they suffer the same flaw as memory - you can forget to put something on there. 
i’m surprised this (making a list) is considered anything more than common sense to be frank. if someone has to be told this, they probably lack the natural aptitude to manage a project… still, i guess we must respect the training courses etc… its the way of the world.
although i will say the biggest project i work on with a list of objectives has slipped and slipped and slipped due to my failure to anticipate how much programming i am really going to do in my spare time.
moral: bad programmers can still run late with good lists.
I started having the same problem in my side-project - we were concnentrating on the big items, forgetting about the smaller ones. I’ve tried writing things down, and after 2 months of trying we ended up on trac integrated with our source control subversion.
Very nice way to go, you can add things to be done in a flash, from anywhere, so that you don’t forget them.
Yep, a list of task or to-do list really helps me do my work and know how far I am from finishing. I keep it on paper for now and always add items as I find out about them.
It’s a good incentive to keep on working too when you see the list getting smaller and smaller.
Having a list is excellent, but you have to make sure your team understands that you cannot check off a single item until it is truly done.
Not code complete, not done but still needs tests, or done but needs refactoring. Not done means you delivered zero business value and thus you cannot show any progress (doing so would be lying). If you show the illusion of progress then you aren’t painting the right picture to your stakeholders.
It’s amazing how many programmers consider something done and then still work on it for hours (or days) longer to polish it.
i’m 90% done reading this blog.
I just finished reading Time Management for System Administrators
http://www.thecrumb.com/2008/07/18/book-review-time-management-for-system-administrators/
And he had one good mantra: List the Work. Work the List.
I’m trying to use my bug tracker and Outlook tasks more and it’s helping. Now I need to start busting those up into more sizable chunks…
Well done, Jeff.
I’m glad you owned up to your project management blooper. While I agree with Joel that this project’s slippage is not a major issue in this case, the average developer is often faced with projects where schedule slips are disastrous. Thanks for setting a good example to all the shoot-from-the-hip estimators.
I think many a developer’s pain in this area comes from being poorly managed. They are asked for a rough estimate on how long it would take to do x. They provide an overly optimistic estimate, and the project is approved on that basis. If they develop a realistic schedule and present it at this point, they are often harshly criticised for their inaccurate rough estimate, and the criticism continues through to the inevitably late delivery. If there is no schedule, however, the developer can continue to claim that he is 90% finished, and defend any unforeseen problems that may occur.
I have learned that the only way to counteract this pattern is to refuse to be drawn into giving a rough estimate for anything, and always asking for a complete requirements spec, whereupon I make the schedule and give the schedule as the estimate.
Keep on blogging, young Jedi.
Semi-OT: For someone who likes it BIG and ROUND, your yellow-boxed ad at the bottom of your posts aren’t very clickable…
Don’t forget to include a line item in your time estimate for BSaP.
That’s B.S. and Politics. All of the things that suck up your time, but have nothing to do with actually producing the end product. Meetings, convincing execs that the tool they heard about in some tech journal may not be the best thing for this project, etc.
Ha. I work at Nucor (referenced in the Poppendieck article). Its a great place to work for the most part. There are problems with the incentive system, but its far better than the alternatives. Basically what Nucor has done is get all of its people focused on making more money for the company. If the company makes more money, we (the employees) all make more money. Its clear how to make more money … produce more steel! Its not a principle that would be easily applied elsewhere.
I agree, this is the only way to have accurate estimates and prevent the 90% done. I believe she wrote an article a few years ago and coined the term inch pebbles for these tasks.
And once you get your estimate, you still need to factor in the unknowable unknowns that pop up as you code.
Jeff,
You’re one awesome dude!
I listened to the podcast where that caller called you out for being behind schedule. I listened to Joel being the prick he sometimes is when he teaches others. Although I agreed with both of them, you should have kept track of your tasks, I don’t think they taught the principle effectively. In spite of them, however, you had the guts to recognize your mistakes. I wish you success in trying to correct them.
I’d like to see a success story of this system being used on a real project.
If you don’t have a list, you never know when you are done or if you’re late.
Most people don’t update their schedule when they update their list.