Are Programmers Really to Blame for BAD Estimates?
Agile Development • Lean Startup • Software Company Culture
When programmers estimate code on software projects and they turn out wrong, who's to blame?
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
When programmers estimate code on software projects and they turn out wrong, who’s to blame? Are there other reasons why estimating software development projects produce bad results – that are outside the control of each programmer? 🤔
In this article, I share some of the unique properties of estimating code. Programming is impacted by attempting to predict it, differently than many other types of work.
7 Reasons Why Programming Estimates Are So Unreliable
#1 Not Repeatable
Much of the way we manage modern software projects is still stuck back in World War II methods for measuring the productivity of producing physical (and not digital) goods. Consider a worker who uses a drill press to make holes in a metal part as one step in an assembly line. There is only a very minor variation in how that job is done from day to day. Things are pretty consistent. Other workers can be hired to do the job, and if someone is sick or needs to have their shift covered, the skills transfer between people easily.
In software development, each user story assigned to a developer is a one time task. It’s being performed for the first time ever by that person, and it will never be performed again! So estimation is not as valuable since any change in who performs it will require a different person to be involved. That person will write the code and implement the feature differently. You know this, because if you go out on Leetcode or Hackerrank (popular sites used for programmers to practice algorithms), there are multiple correct answers. Any change in staff immediately renders the estimate of little value.
#2 Too Many Variables
Software engineers encounter thousands of keywords, statements, and configuration options every day to do their work. This is alongside the complexity of the business domain, and the interpersonal challenges of communicating and working with people having different perspectives on a team. On top of that, we use technologies that have been built by other companies as part of our work.
No matter how good of a job developers do trying to think of how they’ll write the code when they estimate, they don’t really know the effort until they actually DO it. Tools like UML modeling attempt to help developers think through things at a higher level of detail. But even then, no up-front design of software is sufficient. All software tasks encounter uncertainty, unexpected complexity, and ways code must be written that could not be discovered until the work is actually underway. This leads to estimates that assume a level of certainty of how work will progress that don’t match the nature of coding.
#3 Surface Understanding
Business people are excellent at understanding their customer and working together to come up with high level ideas and designs for how to offer solutions. But once they communicate these to developers, it is never at the level of detail needed to write the code. Programmers ask clarifying questions, and sometimes this can be exhausting.
Edge cases, complex business rules, and special scenarios that were not considered by the business at first – suddenly have to be figured out before work can proceed. And sometimes management can get tired and impatient – cutting corners on answering questions if driven by fear and urgency. When this happens, a surface understanding of the work needed, can render estimates overly-optimistic and unreliable.
Most of the recent videos on my channel end with an #episodegroove where I’m sharing little snippets of music I’ve written over the years. 🎸
#4 Unique Integration
When a home builder is constructing a custom home, they can spec it out using engineering standards, known suppliers, common materials, and typical market rates for labor costs. In software engineering, products are a unique combination of code written in house, leveraging software toolkits and APIs provided by other vendors. There are no standards around building each software product, because it’s one-of-a-kind.
When code to integrate systems together is written, it’s being done for the first time ever – so programmers don’t know what hidden problems they’ll encounter. No matter how well documentation is written, if gaps in functionality of a dependent technology are encountered, an alternative strategy must be put in place to continue. Sometimes this requires a complete rewrite – or swapping out of a different technology.
When this happens, the product development must still go on. The original estimate is blown and ultimately useless, and the project may appear “late” when it’s simply the nature of the beast of unique integration.
#5 Low Diagnostic Output
Some of the tools programmers use to make progress when coding are logging, monitoring, and other troubleshooting techniques. When they use a third party Software as a Service (SaaS) platform, library, or API – they depend on the vendor of that dependency to provide adequate diagnostic output to troubleshoot issues.
Unfortunately, this is one of the first places companies often cut corners during a time crunch. I’ve been on projects where two weeks of unexpected effort were spent simply figuring out why there was a memory leak in another company’s technology we depended on under a certain situation. No StackOverflow answer could help us here…
Since we can’t often know the quality of error handling and diagnostic output available in a technology until we begin to use it, this can be a huge source of uncertainty rendering typical estimation activities marginally useful at best.
#6 Knowledge Work Mismatch
Software development is knowledge work. We don’t produce a product by moving our bodies to interact with machinery (OK, we type on keyboards…🤣) – we use our mind. The way we improve productivity on a software development team is not by working harder or faster, it’s by coming up with more creative solutions. And these solutions aren’t discovered during planning. They happen while we’re in the middle of writing code!
Creative solutions to problems let us write less lines of code, make it faster for team members to read and reuse each other’s code, and offer a solid foundation upon which future changes can be built.
When software engineers are placed under pressure, it prevents them from having the time needed to think about the problems they’re solving in each user story – and choosing the most appropriate design. This isn’t about perfection here – it’s about exploiting the unique aspects of software development that increase productivity.
If you manage software developers and put them under unnecessary pressure, you’re actually fighting against what you want! With estimates that are too aggressive, productivity plummets and programmers often quit.
#7 Undervalued Teamwork
In traditional manufacturing assembly lines, the jobs workers do are designed to eliminate any dependence they have on other people. The idea is to make their job as focused and productive as possible. While it may take multiple people doing upstream and downstream tasks to produce a product (like an automobile), their individual task can be completed without much collaboration directly from anyone else.
In software development, we all work on a shared product. The code one person writes is often reused by the entire team, so any changes they make to it also impact everyone else. And since software development is knowledge work, we often need to consult our colleagues to bounce ideas off them to get through problems we encounter.
Estimation in software development is often unreliable because it assumes very little teamwork will be required. In reality, there is no way to predict who will need help, and how often. When we make it hard for people to work together, projects take longer, people are motivated to keep to themselves – and the resulting code makes any future development slower.
6 Ways To Reduce the IMPACT of Bad Estimates
If you’re on a team with true business agility, estimates may not be that important. In that case, the company has the humility to realize software development is an unpredictable activity, and the product needs to evolve based on customer feedback.
For the rest of us, how can we reduce the negative impact of what happens when the estimates turn out to inevitably be wrong?
#1 Reduce Estimated Work
If you think you’re going to estimate 6 months worth of work, anything going wrong is now multiplied times the total number of things you estimated!
So if you want to reduce the negative impact of bad estimates, predict less! Commit to less! Many people don’t understand that story points, the unit we often use to estimate in scrum, are not meant to be a unit of time. The purpose is to break work up into the smallest units possible and pick small things. This is so the IMPACT of bad estimates is smaller!
#2 Keep Estimates With Estimators
Since every developer writes code differently, when we make an estimate, we’re making assumptions in our mind about how we would write the code. Even if your team is doing planning poker, there are always unspoken assumptions about how the code may be written that are in the minds of those contributing to an estimate.
So if you assign a developer to a task they didn’t estimate, you’re asking them to somehow know what was in the mind of another person at the time they estimated. Don’t do it! If your team is forced to estimate, you must do everything in your power to make sure the person doing the estimating – is the same one who implements that work.
#3 Estimate In Components
To complete a task, there could be user interface components to build, backend APIs, business logic, calls to third party services, and database schema changes needed as some simple examples.
Since the business is usually good at communicating what the user interface needs to do, programmers must spend time thinking about the rest of these components during any estimating activities. Yes, there’s no way to know exactly what the code will look like until we build it. And as I said earlier, that’s a big reason why estimating is of low value. But if you don’t think through all of these things that need to be built as components – YOU as a programmer are to blame for a significant portion of the reason why an estimate is wrong!
#4 Choose Familiar Technologies
As software developers we often want to work with up and coming technologies because we believe that increases our value in the marketplace. But if you step back and really look at how our industry works, new technologies are often lauded as “the next big thing” only to die out in a couple of years.
If you really want to have less stress on your software project, consider choosing more proven technologies. Does this mean you have to use old moldy technologies? Absolutely not! But there is a difference between leading edge technologies – and bleeding edge ones (don’t cut yourself!). When you choose proven, popular technologies in use at many companies, you have a bigger support base, hopefully higher quality to build upon, and reduce risk.
#5 Find Native Integrations
Some of the most unpredictable work we do on software projects is not using our favorite framework or library. It’s connecting together two systems, designed in isolation. Whenever we do integration work like this, we have to translate between the API of two platforms that may have different paradigms for security, data access, error handling, and other aspects of information technology.
If you want to reduce the impact of bad estimates, try to find native integrations. These are two systems where one has a native “connector” or “provider” supported by that system already designed and built to exchange information with the other. This increases the return on investment of integration because now your team doesn’t need to build it, test it, support it, and troubleshoot it.
Yes, it may not do everything you could possibly think of that you might want as far as integration between the two systems. But if it meets the needs of most of your requirements, you can sometimes convince the Product Owner of the benefit since it will save costs and get value out to their customers faster. And it will reduce the things the team has to estimate – and find out are more complex than they could predict!
#6 Stop Using Estimates
The final thing we can do to reduce the impact of bad estimates, is to just stop estimating altogether! I won’t go into a lot of detail in this article since this is a complex topic, and gets into how management measure progress and confidence is maintained with people who invest budget in the software project.
But if you truly want to deliver the best return on investment for your company, deliver the most valuable features possible for customers, and get the most productivity out of the software development team – estimates work against that. All the time spent in meetings trying to predict the future, argue about why things turned out differently, or reset expectations with people who commitments were made to can be spent on delivering quality software instead. And that’s what makes a profit – not hitting deadlines!
After 25 years on nearly 40 software projects, I’ve recently met over 200 IT professionals online, helping them reach their career goals. Need help with your career? Book a free software development career coaching consultation.
Whether you’re estimating code for a scrum, kanban, or any other type of project – estimates should be treated as a minor help in the form of a tool. A tool for reducing extra time spent when unforseen complexity rears its inevitable head. But never as a commitment that we use to measure a programmer as a proxy for how good of a job they’re doing!
Creativity is the most important aspect of software development. And we don’t get creativity from developers who are overworked and burned out. We get it when they have the time to think of the most creative and elegant solutions. Creative and well-designed solutions save tons of lines of code for not just the person who wrote them, but everyone who benefits in the future. This is the productivity a company really wants. So let’s not fight the nature of the knowledge work we really do on a software development project!
Skip To Points In The Video
- 1:19 Why Programming Is Unreliable
- 1:26 #1 Not Repeatable
- 2:06 #2 Too Many Variables
- 2:50 #3 Surface Understanding
- 4:06 #4 Unique Integration
- 4:59 #5 Low Diagnostic Output
- 6:08 #6 Knowledge Work Mismatch
- 7:19 #7 Undervalued Teamwork
- 8:20 Reduce Impact of Bad Estimates
- 8:42 #1 Reduce Estimated Work
- 10:06 #2 Keep Estimates With Estimators
- 11:26 #3 Estimate In Components
- 12:50 #4 Choose Familiar Technologies
- 13:56 #5 Find Native Integrations
- 15:04 #6 Stop Using Estimates
- 16:10 Episode Groove
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.