Mere minutes ago, a Tweet showed up in my stream that asked for freelance .NET developers saying they had a 160 hour project spread out over six weeks that needed doing.
That’s pretty amazing how they knew the project would take 160 hours / six weeks. Does CNN know about this? Just think of all the good this company could do predicting earthquakes and volcanic eruptions and so forth. It’s awesome how they know with such precision how long their project will be.
I think from here on out, I’m going to deal with everyone as if I know how long it will take them to do the work I want.
“Any painters out there? I’ve got 12 hours of painting that needs to be done.”
“Any attorneys out there? I’ve got 4 hours of lawyering I need someone to take care of.”
“My tooth hurts. I need an hour and a half worth of dentistry, please.”
It sounds ridiculous when you apply this to other fields, so why is it so commonplace in software development projects?
A far more realistic Tweet would have been something like:
“I don’t know how long this project will take you, but I’ll pay you for 160 hours, and I have a hard stop at six weeks, so you’ll have to do whatever you need to do to finish by that date.”
This also kind of sounds silly, but at least it portrays the reality, and it’s the reality of how most software development projects are planned.
I don’t care how much acumen or experience you have as either a developer or a project manager, you cannot dictate how long a software development project will take. You can’t. No, you can’t. “But…” No, but nothing. You cannot. Can. Not.
You can dictate how long you wish it would take. You can dictate how much you’re willing to spend. You can define whatever factors raise hard deadlines you can’t work around. You can’t declare in advance how long development will take. Heck, this guy didn’t even know who the developer would be. Does he seriously think that every single developer out there will take 160 hours to do his project?
This is why a metrics-based approach provides the best projections. Do a little of the work, measure it, and use that to project the rest. Do a little more of the work. Measure it. Refine projections. Rinse and repeat.
You can budget and plan based on reality, or you can do it based on what you wish reality was.
Next time you go looking for a developer, don’t tell them how long the project is. You don’t know. Define the parameters you’re willing to live with for budget and timelines and see if the real projections sustain those parameters. Anything else is just guessing.