Are Programmers Really To Blame For BAD Estimates?

When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer?

In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers.

There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates.

In the second half of this episode, I share some things I've learned we can do to really increase the chance that if we are forced to estimate, and our coding tasks turn out to take longer than we predicted, the impact to the business is smaller. The simplest thing is for any programmer to reduce the amount of things they estimate. We should also try to be a little more conservative when we choose the programming technologies we use on our software development project. More proven technologies will inherently have less uncertainty and be easier to troubleshoot and support. And whenever we need to integrate technologies together, finding a SaaS product or API that was already designed to integrate with another natively, takes a huge burden off the team.

Whether you're estimating code for a scrum, kanban, or any other type of project - estimates should be treated as a tool to help increase the odds that valuable features get delivered to customers. 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. This saved tons of lines of code and 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!

#programming #estimation #code


RELATED CONTENT

Creative Software Development - Explosive Growth By Letting Go
https://www.youtube.com/watch?v=e48KPylwaB4

Why Does Scrum Make Programmers HATE Coding?
https://www.youtube.com/watch?v=HURvJDldVGA

Is Planning Poker Safe On Your Team?
https://www.youtube.com/watch?v=KIP6x7I8n2Y


Need help with your career? Book a free career consultation:

https://jaymeedwards.com/services/software-development-coaching/#free-consultation


CHAPTER MARKERS

0:00 Introduction
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


Download a free software development career guide from my home page:

https://jaymeedwards.com