Being a great coder is only part of the skills required to be a professional developer. A professional developer is never isolated with the code. All work is done within the context of a project. A professional developer delivers not only high quality code, but also high quality time estimates.
Back in June I wrote about programmers’ time estimates. With more than 100000 views of that post and a lot of interesting comments I want to take a closer look at a common mentality if developers.
Time estimates are impossible. It’s done when it’s done.
That mentality is totally incompatible with being a professional developer. Let’s look at a software project from the perspective of some of the stake holders and see why accurate time estimates are essential for them. It’s not only a matter of some accountant wanting to know the cost for the project. The time estimates are often a key factor when making decisions on what to do and when. Those are decisions that in the end affect the developers.
As a professional developer I definitely have an interest in getting the estimates right, because if they are wrong some bad decisions are going to be made. I think we all know what bad decisions in a software project means: Developers having to work overtime. I don’t like it. Do you?
The Product Owner
The product owner in a Scrum project is the one creating the prioritized product backlog. The order of the backlog is often described as based on business needs only. When the backlog is showed to the developers, the priority is already fixed.
The problem with that description is that it is completely wrong.
It assumes that priorities can be set based solely on how much the business benefits from each feature. To make an informed investment decision (if a feature is to be implemented or not) both estimates of the benefits and estimates of the costs are required.
To a layman it’s often impossible to figure out how hard a specific feature is to implement. I’ve often been involved in discussions where the product owner is a whole magnitude wrong on their gut feeling of how much time a task will take. When I inform them that a specific feature can be implemented much faster than they anticipated, the cost benefit analysis is completely changed and the feature often become more prioritized. The other way around of course happens too – when they realize how hard a task is, the cost becomes larger than the benefit and the item is removed from the backlog with a note “not worth it”.
To enable the product owner to make an informed decision, a time estimate is needed. That’s why I always give a preliminary estimate when I’ve approved the requirements of an item.
The Resource Owner
The product owner is probably the one most directly affected by the time estimates, but certainly not the only one. Somewhere in an organization there’s always a resource owner. Your resource owner is the one responsible for the budget covering your salary.
My resource owner is my boss. He’s not directly involved in my projects, but there is one thing that is extremely important for him to know: When I will no longer be needed in the project. That’s when he no longer can charge the customer for my time. He must know when that happens, because if he is to meet his budget (including having money to my salary) he must have another project scheduled for me right when the old one stops.
Without time estimates of the tasks in the project, it is of course impossible to tell when it is done and when it is time to start on another project.
The Receiving Organization
When I’m moving on to another assignment, because the coding is done, the project isn’t really finished. For the receiving organization this is when the really tough part of the project begins. It’s time for the business implementation. The operations department must be ready to host the new application. The business must make room in people’s schedules for training on the new system. There might be data migration that that requires huge manual efforts.
The receiving organization must be able to make plans for the business implementation. The plan has to include a schedule. It might even require extra personell to be hired for a period of time. Knowing the delivery time is of course crucial. The only way to know the delivery time is to have accurate time estimates of the tasks in the product backlog.
Being a professional developer not only means producing quality code. It means producing quality code on time. As a professional developer you should set equal pride in your time estimates as in your. Always accept accountability for your time estimates, but only if you have the authority to set the estimates in the first place.