Objective Software Development Time Estimation For The Non-Omniscient
I want to share with you my method for making software time estimates by economizing one’s analysis of timed activities to a cognitively manageable level. Why is this worth your time? Working in software engineering makes you very aware of the value of knowing how to size your work. There are many approaches:
Some people view it as a mystic art, discovered like some pythagorean mystery of secret ratios by which to fudge numbers.
Some view it as elaborate statistics of t-shirt sizes, poker cards, or other units of velocity.
Others just shoot from the hip
If you possess any amount of talent in this industry, you will be asked the question: "When can you get it done?"
The cause of this comes from businesses' need to make plans for a very long term. This might occur for instance when they start to get a glimpse of the market they serve or start a project that might take a year or more. Companies often will put strong visibility into a single quarter, and sometimes rough visibility 1-2 quarters ahead. These often begin as nebulous plans, built on a variety of goals each with specific risk. To take them from existing as pure whim, a long chain of questions is asked that eventually cause a developer to be asked “How long would this take?” This process happens because there are trade offs in strategy. Consider if some feature:
takes 6 months
has high risk and likely will not be done on time
is aligned with the company's target market
earns a million dollars
Versus some other feature that:
takes 2 weeks
low risk and will certainly be accomplished
is not aligned with the target market
earns five hundred thousand dollars
Leadership may interpret these features differently, particularly when they have accurate time estimations.
These tradeoffs must be informed because business branches must align across a long period of time. There is a funnel of customer attraction that starts with marketing first spreading the word to an industry, sales people bringing in those attracted as customers, and finally engineers having an actual functioning product for them when they arrive. If the funnel does not have something of value at the end of the long path, strategy will not succeed to acquire a market, customers may churn, and/or frustration within the organization will happen.
If your career started like mine, you probably once felt when estimating that you could not predict that far in advance (especially when measuring for a team as a whole). You might give a good estimate of how much code you could write in 5 minutes, but not over 5 months. The consequence of this for my career was my teams and I always felt like we were being too ambitious but couldn’t put our finger on why. Software engineering veterans inevitably come to the conclusion that “we don’t have as much time as we think'', but we must understand exactly what causes this for our conclusion to be useful in making change.
What makes a good estimation system effective is how deeply you have identified fundamental action in your business quarter. What do I mean by fundamental? I mean that in a given quarter, there is action that is essential to creating product features (i.e. if the action is missing, the outcome will certainly not happen), and there is action that is non-essential. You must have evidence of what this fundamental action is and how much of it you have. Rather than looking inward, you have to look outward toward objective action. Thus, this method begins with a deep analysis of how people spend their time.
Warning: the following numbers are estimates chosen solely for the purposes of explanation.
Human Time
At a high level, we can think of a programmer's time divided into at least four parts:
It is well known that humans do not work 100% of the time at the job. While true, it can be difficult to admit in a workplace. Businesses, however, do not benefit by ignoring this reality and hoping people will somehow “make up for it”. Before you even get to work, you must first be human. What does being a human mean in a work perspective?
Humans need rest and will take vacation. They need this not only for their personal health, but also to be productively optimal. This use of vacation includes fixed holidays but may also be sporadic.
Humans occasionally get sick or have major physical changes that require time off. This can happen at any time to anyone. We should not be assuming your team will be forever in a singular state of health.
Humans have psychological inertia. Let’s face it, you aren’t at the top of your game all day and every day. Monday morning before you’ve had your coffee is not the same as Wednesday afternoon after you’ve been two days deep in thinking about problems.
Humans do not transition effectively. We do not instantly start typing the second we end one meeting. These little buffer zones between activities eat away at our time.
Humans have a social need for companionship and assurances of where they are. Perhaps they have coffee breaks with people, attend all hands, lunch and learns, company parties, or have 1 on 1s with their boss. Many of these meetings happen at regular intervals.
Humans leave companies. We can’t assume people will be at your company forever in the grand vision of their career ( though by reading articles like this you are certainly encouraging it! ).
Needless to say, this human reality takes a huge chunk out of people’s time and must be acknowledged. Even among teams of entirely smart individuals these limitations exist. They derive from natural limits of the consciousness and body.
Product Time
After we subtract out human time, we need to further divide the time allocated most directly toward the company’s product goals. There’s a number of subcategories:
Product roadmap features to acquire a market.
Tech debt not on the product roadmap to make more maintainable code or reduce costs.
Innovation and growth tasks to let teams be prepared for new challenges and making radical decisions more knowledgeably.
Sporadic work to prevent churn of valued customers
Not all work for the product road map is equal. The fundamental action that creates product features is literal coding with hands on the keyboard. There’s a number of supportive actions that surround this fundamental action, each existing in various ratios relative to the time of the core action of programming. For example, if there is 2 days of programming, there’s might some amount action surrounding it:
Product meetings that had to happen to make the days of programming informed.
Coding practices your team has decided to do to maintain quality: automated testing, documentation, etc.
Work that gets sent back from a tester to fix some hopefully minor bug.
Meetings for a software development methodology (Agile, SCRUM, Kanban). These meetings synchronize information, raise blocking issues, and demonstrate what’s been made. One should pay close attention in particular to code freeze dates (if they exist) as they represent points in a cycle which no coding can occur.
Quarterly planning also requires time itself. This is not a trivial task as it requires the orchestration of the product to come up with potential features for developers to understand/break down/size/compare. During this time leads will naturally be directly involved more than others, but often they will have to ask questions directly to programmers due to their limited knowledge/familiarity of specific areas. Involving non-leads is also crucial to get a sense of commitment. If an engineering team is going to say “I commit to this quarter” with full honesty, they have to be asked to evaluate it to a degree with their own mind.
Risk
An additional dimension to time allocations in a quarter is the level of risk. At least two kinds of risk exist:
Risk of the role performing the activity. Experience is unequal in any company and it should be taken account of that some individuals will need more time to get to solutions than others.
Consider a junior programmer or new employee for instance, and the reality that a sizable percentage of their time may be applied to researching an existing codebase
Even fully trained employees may not get the right architecturally aligned implementation written on the first time around.
Consider that bugs are more likely to happen in complex work with many aspects to get right vs simple one liner changes.
Risk of product change
Not all work is equally well defined. Product and design hit limits just as programmers do. You might get into a quarter unprepared with product requirements and should treat that risk appropriately.
Discovery can happen at any minute. A customer might tell you some detail of how they use their product that completely changes how it gets implemented.
All these risks need to be accounted for if one has meaningful evidence. For instance, imagine a full time programmer who has been at the company has 40 days of work scheduled in a quarter. One might observe through experience when they operate in your codebase that 90% of effort is hands-on coding time that reaches the final code base, 10% might be rewriting. A different codebase may have different proportions! In another aspect, you may form an observation that 20% of all features tend to be complex development tasks with high risks of bugs, and 80% of tasks are simple with low risk of bugs. Again, you must integrate this observed risk and adjust the amount of expected bug time if you see it.
When it comes to risk, you should always assume the maximal risk. With quarterly planning, the importance is that leadership knows what to expect 100% of the time. If you do more work, that’s fine, and importantly should be appropriately recognized. Only by carefully reflecting reality and risks will your victories above and beyond be apparent.
Aggregating of Variation
Finally, one must take these numbers and aggregate them into the engineering organizational structure. This is highly dependent on your own company and possibly who you expect to join or leave. Work is typically done by teams oriented around a primary aspect of a product they are familiar with. Each of the individual roles of that team contribute a certain number of hours of raw coding time based on experience. If, say, I had:
A lead with 6% of her quarter toward coding ( time being taken by mentoring and leadership communication )
2 standard devs with 10% their quarter toward coding ( have maximal potential of time )
1 junior dev with 7% of his time toward coding ( inhibited by unfamiliarity with a codebase or programming concepts )
These percentages can come up with a maximum real coding time number that can be brought to the quarterly planning. Perhaps you say, “We only have 10 coding weeks” total for a team we can apply toward some domain of features. This indicates if features will be completed fully or partially, and may suggest a re-org, hiring, etc. is needed. Ideally even a rough estimation of this is known in advance of the next quarter to start a hiring process early.
Importantly too you must recognize the contextuality of individuals. You’ll want to know if members of one team are taking 2-3 weeks off for December holidays or saving them for a spring trip to another country in a different quarter. Don’t be the engineering leader who sets his team up for failure for not accounting for holidays (and the mental recovery from these necessary detours from productivity)!
Conclusion
The goal of this method is to reduce the number of considerations when assessing how long features will take to be done. After you have subtracted out objectively based allocations of human time, meeting times, development supportive tasks, and risk, the question is much simpler to answer. 3 months of time may in actuality be only a few weeks of actual hands-on coding time on a keyboard. Programmers are far more capable in making commitments when they can clearly imagine a continuous time of optimal conditions for programming they can see from beginning to end.
This is a method for making an estimate appropriate to man’s consciousness and its limits, it is not an attempt to generate a one size fits all answer for every company under the sun. No person can write a divine pie chart for all companies and their permutations of experience, quarterly holidays, software development methodologies, roles, codebase complexity, product domains. Making estimates for NASA computer scientists is not the same as doing so for a startup focused on a social media app, so focus on the essential activities you can see contextually in your own company. I personally put all my formulas in an excel sheet and visualize a cycle of development time (2 week sprint) to validate where I see hours being applied. I hope you have fun assembling your mental model of your team in the tool of your choice. There's an aesthetic value in seeing a massive chart of all these numbers with your colleagues and saying: "This is who we are", and an even more important career value in being teams that can be trusted to meet expectations.
May your path be planned, and your successes be seen!