Jan 3

Written by: Paul Mehner
1/3/2008 8:31 PM

There a lots of systems out there for estimating software construction, but I think Joel Spolsky hits the nail on the head with his article on Evidence Based Scheduling. It is truly a "must read" for all members of the development team.

I’ll probably come across as being a little jaded, but please bear with me. Ten years of providing services to government agencies have lead me to believe that many state government project managers really do not want to know the true amount of time that software development is going to take. It's not relevant to their process. The public and the state legislature establish the schedule and the budget and often the development teams are the last to learn of the "estimate". DIS provides project management “oversight” (which amounts to hitting the project manager over the head about their performance whenever a task runs longer than the legislature thought it should take). Ever play red-light-green-light? Oh what fun! Rewards often go to project teams that complete on time, not the ones that have the lowest defect rates, the lowest TCO, or the easiest maintenance. Write spaghetti code that sucks but complete your projects on time and you’re still a hero. Write elegant easy to maintain code, but be a day late, and you’re considered inadequate.

I’m not quite as jaded as I may sound in this blog entry. Knowledge of what a task is truly going to take can provide some strategic capabilities to the development team, even when operating in such an ecosystem. I work from the inside for improvement of the process, and our .net user group is just one of the ways that I attempt to do this. Part of this work requires recognition of the problem and the factors that contribute to it, and that are where posts like this one come to play. There should be no offense taken by state IT project managers, as none is intended. We all work within a system of constraints, and I understand that.

Tags: