Anybody who’s done professional software programming for a living will have heard this a bazillion times by now, and for those programmers that are just entering the field, be prepared to hear this from every person you’ll eventually have to report.
“How long is this going to take?”
It’s too bad I didn’t have a nickel for each time I’ve heard this, because I would have been able to retire a long time ago, sipping tasty Pina Coladas on a sun-soaked beach.
It doesn’t matter what kind of technology stack your company uses, the kind of development methodology your team practices (agile, waterfall, lean, etc…), or the product or software deliverables you actually produce.
The most important thing that matters to a business or organization is WHEN IS IT GOING TO BE READY TO SHIP?
It’s a bit ironic, but many of us software engineers find that trying to come up with a definitive answer to that question is infinitely harder than trying to figure out some brand new programming language we’ve never used before, or figuring out how to implement some extremely complex computer science algorithm.
As a matter of fact, many software engineers will go out of their way to avoid answering that question, for the following reasons.
- We don’t like committing to completion dates
- We don’t like looking bad when we miss those dates
- We get pressured to change our completion dates
- Accurate completion dates are extremely difficult to calculate beyond a certain scope
Reasons 1 and 2 pretty much go hand in hand.
While software engineers consider completion dates as estimates, management often considers completion dates, even if they are supposedly “estimates”, as being chiseled in stone more permanently than the Ten Commandments.
Reason 3 happens quite often as well. When we software engineers attempt to give realistic completion dates, factoring in things like learning new technology, shifting and changing business requirements, and adequate time for QA testing and documentation, what often happens is management will try to weasel their way into persuading you to either change your estimated completion date to something more to their liking, or even worse just force their own completion date deadline on you, with or without your consent.
They’ll often use tactics like managerial pressure, or say things like “oh, don’t worry, we’ll just throw more resources (that’s their term for ‘people’) on the project, so don’t worry about the deadline being shorter”.
It’s a sign of disrespect to the engineers, who are the ones actually responsible for rolling up their sleeves and doing the work necessary to complete the project.
And I’ve concluded the root cause behind much of the high-pressure negative tactics coming from people who don’t have a technical bone in their body.
I’ve blogged extensively about the problem of non-technical executives in the past, and the clearest, telltale sign you’re going to be pressured to work harder and faster while at the same time, sacrificing overall code quality, is when your company is staffed by people who don’t have the faintest idea what kind of technology powers a company’s products and services.
But the final reason, and probably the most important, is why I think project time estimation doesn’t work beyond a certain scope.
Imagine you’re the head engineer in ancient Egypt and the Pharaoh suddenly asks you to build a giant pyramid to hold his tomb.
Perhaps the conversation sounds a little like this …
(Pharaoh) “Hey Bob old buddy, I need a giant pyramid-shaped tomb to hold my final resting place, and it needs to be gigantic and impressive looking and needs to last thousands of years.”
(Bob the Builder Engineer) “Uhm, err, my lord, I’m not sure that’s even feasible. It’s never been attempted before, so we would need a team of my engineers to analyze the problem and …”
(Pharaoh) “Feasible, schmeazible, don’t give me any of that poppycock…why just yesterday, I was flipping through CIO magazine and I heard about this totally awesome new way of working on a project…it’s called ‘agile’ and it lets you get a project done quicker and better, and the best part is it doesn’t require any sort of project analysis or any other of those time wasters! Here, read my copy, I’ve already skimmed through it, I’m sure you’ll find it more useful than me, after all, I’m not the engineer, you are.”
(Bob the Builder Engineer) “But my lord, you’re asking for the impossible, I don’t even know where to begin, I have to talk with all my senior engineers before we can even begin to scope out what it will take to complete this project. So why don’t I get back to you and once we’ve spent a good number of months analyzing what you want, then we can begin working out some preliminary high level …”
(Pharaoh) “Oh, one more thing I forgot to ask, how long is this sucker going to take? Remember, I ain’t gonna live forever, and we need to show the world that we Pharaohs die just as grandly as we live, right? So how long, Bob?”
Ok, I admit, I wasn’t there in ancient Egypt during the time of the pyramids, but I’ll wager even back then, engineers were expected to come up with completion dates for their projects, just like we’re asked today.
The problem is that calculating completion dates gets exponentially harder to figure out as the scope of what you are trying to estimate gets larger and larger.
Imagine you’re that poor engineer who the Pharaoh corners and demands you tell him how long it will take to completely build the pyramids of Giza. How do you even begin to give an answer? It’s estimated that it took ten to twenty years to completely finish, but I doubt the original engineers behind the Giza pyramids were anywhere close to accurately estimating that number.
The scope of the project is just too big. Project estimation is even harder when there are unknown factors you don’t have answers for.
[bctt tweet=”Project estimation is even harder when there are unknown factors you don’t have answers for.” username=”profocustech”]Yet that doesn’t stop management from asking engineers for accurate project completion dates.
Waterfall development was big on final completion dates.
As a recap, waterfall development is all about analyzing project requirements until you end up with a finalized project plan with an estimated completion date at the very end.
The problem with the waterfall approach was that the project scope could end up being quite big. Not to mention that project requirements would often change, thus negating any initial project completion dates.
The agile methodology movement came about to address the perceived shortcomings of waterfall development.
Instead of attempting to figure out how long the entire project will take to complete, agile breaks down a project into smaller pieces. A developer does not have to wait until the complete project requirements have been created.
Instead, the developer thinks about how long smaller pieces of the project will take.
But even trying to calculate how long “phase 1” of a project will take can be near impossible.
I believe software developers need to break down project requirements even further until they get small enough that you can actually estimate the number of hours it will take to finish.
For instance, I can’t tell you, with any degree of accuracy how long it will take to build an entire web application on a certain date.
But what I can do, is give you a time estimate, in number of hours, for how long it will take to design the login screen of that same application.
You really can only accurately estimate tasks when they are of small enough scope that you can wrap your head around the amount of time it will take to finish the task.
And at least for me, that means in measurements of hours, or at most, a full 24 hour day.
Look, I get it.
Completion dates are important. Shipping working code in a production environment is important.
Until that happens, a software developer isn’t proving their worth to a company or organization.
Shippable software creates revenue for the company and pays the bills as well as our comfortable salaries. No ifs, ands or buts about it.
But it’s important to break down project requirements into small enough chunks that a developer can actually estimate with some degree of accuracy.
But come on guys, be realistic about asking developers about completion dates.
You might as well ask how long it’ll take to finish the pyramids.
And I doubt that ancient engineer stuck around to answer the Pharoah’s question either. He probably started browsing glassdoor.com as soon as he was excused.
