A growing number of developers, rallying behind the Twitter hashtag #NoEstimates, believe that estimation is a deeply flawed software development methodology. Estimates, according to these developers, are not only imperfect and ineffective but an unnecessary evil invented by businesses to pressure developers into meeting unrealistic deadlines. Naturally, as with all great programming debates, advocates believe they are fighting a Holy War.
As someone who, at different times, has been a developer, manager, product owner, and now a business owner, I can confidently say that estimation is not your enemy. In fact, estimation is one of the best tools we have for measuring velocity, efficiency, and productivity, and therefore is one of the best tools for dramatically improving your performance as a developer. Peter Drucker, the author of The Effective Executive, said it best: “If you cannot measure it, you can't improve it.”
The NoEstimates crowd is blind to these benefits because they believe a series of untrue myths about estimation. These myths are rooted in a misunderstanding about the purpose, execution, and value of estimation for developers, managers, and clients. The following series of articles will dive deeply into software estimation starting with these myths of estimation, why developers should learn to estimate effectively, and the proper mindset one must have for estimation. Further articles will expand on why estimation is necessary, why understanding the work is important, how to estimate effectively, and finally how to work against estimates.
Myth #1: Estimates only benefit management and businesses
The narrative from the NoEstimates movement is that estimation benefits management while developers lose. But estimation is not a zero-sum game, all parties can and do benefit. Estimates allow management, among many things, to gauge developer efficiency, manage product owner expectations, and create realistic timelines. All of these are extremely valuable to any business, which means that developers who can provide accurate estimates are highly valued. Further, developers can easily demonstrate their productivity and ability to finish a product on time, by consistently completing work within the estimate. Providing a highly valued skill to employers will result in increased leverage the employee will have over the organization as well as create separation between themselves and other coworkers. In short, estimates help, not hinder, developers in garnering higher wages and job security.
Developers do not need to worry about whether estimates benefit managers and businesses. As long as they focus on themselves, getting better at estimates and hitting them to garner better wages, everyone will win. This can nicely be summed up by term, The Invisible Hand, coined by Adam Smith:
“...he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention.” - Adam Smith, The Wealth of Nations
Myth #2: Estimates force unrealistic deadlines
Sadly, some managers do use estimates to force unrealistic deadlines on developers. But this says more about the culture of the management team than it does about estimation itself. A team that abuses estimates will likely abuse other methods to force unrealistic deadlines anyway. The problem is with management demanding unrealistic deadlines, not estimation as a tool. Hammers can also be used for harm, but nobody argues that hammers are not effective when used correctly.
Myth #3: Estimates cause constant stress
First, stress is not unequivocally bad. One technique in Cognitive Behavioral Therapy (CBT) is to list all your negative emotions (angry, fearful, anxious, stressed, etc) and assign a percentage for how much you are feeling that emotion in a specific situation. Then go through each one and assign a percentage that you think you should be feeling. The point of this exercise is to realize that in every situation there is an optimal level of stress we should be feeling. Feeling stressed or anxious about an upcoming job interview is not only perfectly normal, but it is also necessary for you to be on point. Achieving 0% for all negative emotions is an unrealistic goal in a modern world filled with bills, relationships, and family dynamics all out of our control. Unless you plan on becoming truly enlightened and sweeping a monastery for 12 hours a day, you should plan on optimizing your stress levels to help you achieve your goals.
While estimates certainly can cause stress, they by no means need to increase stress beyond an acceptable and manageable level. By understanding how estimates work, how to think about estimates, and finally how to use estimates effectively we can reduce stress to a minimum. This article, and subsequent articles, will cover each of those points in sections below.
Myth #4: Stories takes however long they take
The phrase “a task takes how long it takes” implies there is an objective, absolute, set amount of time a task will take to complete. This may be true if we’re talking about the absolute shortest amount of time it would take to complete a task, in the same way, we calculate the absolute shortest amount of time we can get from LA to NY using different modes of transportation currently available. But the maximum amount of time a task could take is infinity, or the lifetime of those involved, due to procrastination, roadblocks, and so on. How long a task actually takes lies somewhere between these two extremes, depending on the productivity and focus of the team.
The goal for all teams should be to get closer to the minimum and always seek improvement. Developers who refuse to estimate and say a task will “take how long it takes” risk falling into the trap of Parkinson’s Law, which states that “work expands so as to fill the time available for its completion.” I encourage you to try an experiment to test the two methods. One you plan out, estimate, commit to hitting the estimate and make pragmatic decisions towards the goal of hitting the estimate. For the second one, simply work until you are finished. I guarantee you will have a much higher chance of finishing the first project quicker than the second.
Myth #5: Perfect Estimates are impossible therefore are a waste of time
We wouldn’t call them “estimates” if we were able to perfectly gauge the amount of time a task would take. Scientific measurements are only accurate to a specific decimal place, yet they are still useful. Medicine is not perfect, yet it still saves lives. There are many things in the world worth doing where perfection is impossible. A basketball player will never be able to make 100% of all their shots, but 45% is much better than 25%. In the same way, estimates can still be incredibly useful despite being imperfect.
Both of these views are perfectly valid to hold. There is nothing objectively flawed about either argument. They are subjective statements that both sufficiently describe estimation. The question is not if they are valid, the question which one is more useful to you?
Myth #6: Estimation is an innate skill
The myth that various skills are natural or inherited is found in almost all possible activities. The reality is that skills are earned through hard work and practice. Anders Ericcson’s book Peak illustrates this point excellently by dispelling the myth that perfect pitch is innate by telling the story of Mozart’s childhood.
By the time he was six, Mozart was performing for royal courts across Europe. One might assume that being so skilled so young, Mozart was born with perfect pitch and the innate talent for music. However, Mozart’s father was obsessed with music and the first few years of Mozart’s life completely revolved around music. His older sister performed for money from an early age. Mozart himself was being taught how to play by the time he was three. Essentially all of his childhood was spent listening to or practicing music. It is no surprise, with that amount of exposure and practice, that Mozart had perfect pitch at such an early age. Ericsson gives another example of a teacher who successfully taught an entire class of students to have perfect pitch with an hour or two of lessons every day for a few months.
As with perfect pitch, estimation is a learned skill, not an innate talent. Anyone can improve their estimation skills if they deliberately and consistently practice.
Why learn to estimate effectively
Now that we’ve debunked the myths of estimation, let’s look at why estimating is beneficial to developers.
Maximizing value gives you leverage
The most efficient, most productive, and most valuable team members have the most leverage because businesses obviously do not want to lose them. With leverage, comes compensation, freedom, trust, autonomy, and pretty much every positive aspect of work. The equation to gain leverage, therefore, is surprisingly simple: consistently grow, take on more responsibility, maximize your value, and therefore maximize your leverage. Finally, use that leverage to ensure you get what you want out of your work life.
Learning to estimate is the best way to maximize value
If you want leverage and to take your career seriously, then you need to have an active interest in honing your craft. To this end, developers are endlessly obsessed with honing their technical chops. They go to conferences, read blogs, do side projects, follow influencers, take courses, and more. But none of those activities will have as drastic of an effect on your career as honing estimation because it is the one thing in software development that affects all others. Being good at estimation requires that you work in a consistent manner, have strong self-discipline, and be able to deliver on time. Just like any other skill, you can improve your estimation and delivery on the estimates with practice, measurement, and adjustment. Very few give anywhere near the kind of rigor towards getting better at estimating as they do to increasing their technical skills because they do not see the immense effect it can have on their careers.
In short, learning to estimate effectively is the best way to grow and demonstrate value to your employer, and therefore is the best way to maximize your leverage and reap the benefits therein.
Philosophy and Preamble To Estimating Effectively
The following series of articles are for developers, not managers, product owners, or business owners. They are directed specifically at the hard-working, go-getter with aspirations of being the best developer on the team. It is not for those who want to skate-by, blend into the background noise or otherwise disappear into the depths of some large organizational monopoly that allows for dead weight. If minimal effort is your desired goal and “good enough” is your motto, then these articles are not for you.
These articles will also not help you find existential meaning in your work. Occasionally people will say: “If you don’t love what you are doing every moment of the day, you are doing it wrong.” In my experience, this is a naive sentiment, every job, no matter how glamorous, can be difficult, monotonous, boring, challenging, undesirable, or “beneath you.” Accepting that you will not always love every part of your job is important to finding happiness and satisfaction in your work.
There Are No Shortcuts
The steps in these articles are not shortcuts, hacks, or magical formulas. Jocko Willink, former Navy SEAL and author of Dichotomy of Leadership, says it best.
“The shortcut is a lie. The hack doesn’t get you there. And if you want to take the easy road, it won’t take you to where you want to be”.
The “road” that this post describes is not easy, it is difficult and that is the point. If it were easy, everyone would already be doing it and it would be a requirement rather than something that makes you stand out. This famous quote from JFK describes how I approach everything that I do in my work.
“We choose to [do these] things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone...”
JFK perfectly describes what we should all aspire to achieve in our work life. Work should be challenging. This challenge should serve as a goal to “organize and measure the best of our energies and skills.”
Following the framework described in these articles is a similar kind of challenge that requires effort, dedication, and having the right mindset and ability to overcome excuses.
Having the Right Mindset
The two biggest challenges I have seen developers face when adopting estimation described in these posts is not having the right mindset and allowing excuses to defeat them before they have even started.
The criteria for this to work is as follows:
People know how important mindset is to sports and athletics but rarely apply it in other aspects of their lives. If you ask any athlete they will tell you that in many cases the difference between extremely successful and mediocre can simply be their mindset. A major difference between the two mindsets is one gives in to all the excuses their brain comes up with while the other doesn’t.
Excuses are easy. Excuses are a dime a dozen. There are literally infinite excuses that you could come up with for why something didn’t get done. Excuses almost always sound totally reasonable despite the fact that there are still people who manage to run marathons, spend time with their kids, and continue to excel at work. This is the same dynamic at play when you approach an estimate. While working, your brain constantly tries to convince you that there are many valid excuses as to why you cannot finish on time or on budget. You must actively fight these excuses.
Excuses always sound like legitimate problems that really prevented the work from being completed. The problem here is that the job of the developer is to get the work done in spite of excuses. Remember that at the core, your job is to solve problems and achieve the goals of the stakeholders. Most of the time, excuses are simply a list of the things that need to be done. For example, saying: “I couldn’t get my work done because it was unclear which encryption we were supposed to be using.” Figuring out which encryption is the job and is part of the task. What one person could legitimately consider a blocker, another could consider a challenge that they can and will overcome.
Periodically there are real excuses. Excuses that could not be avoided and are understandable, however, this is rare and the exception. You had a death in the family and you had to take time off work or a third party vendor broke their API and delayed your release. If you find yourself leaning on excuses for why you are consistently missing reasonable estimates, you are either the most unlucky person in the world (hint: you are not) or you need to reframe your thinking. You have agency to overcome all of these issues if you approach your work with the right mindset and ownership. Do not be tempted by the easy road and excuse every miss. Take ownership over your work.
The best part about having the right mindset is that the folks who have the wrong mindset are your competition. This is great news for you because they are going to be easy to outperform. The correct mindset combined with the estimation framework described in this post will set you on an ever increasing upward trajectory.
Simplicity of the Estimating Framework
The following articles will go into more depth about the underlying motivations for estimation and explore a detailed framework for estimating effectively. Implementing these changes into your workflow and life will be challenging, but do not confuse difficulty with complexity. The framework described in this series is simple at its core. It is analogous to losing weight. There is nothing complex about getting in shape: eat fewer calories, eat healthier, and exercise more. Thousands of people struggle to lose weight effectively because, while it is simple, it’s also very challenging to show up consistently. Consistently leveling up your skills, efficiency, and productivity to provide the maximal value to the stakeholders is as simple, difficult, and boring as getting in shape.
At FullStack Labs, we pride ourselves on our ability to push the capabilities of cutting-edge frameworks like React. Interested in learning more about speeding up development time on your next project? Contact us.
We’d love to learn more about your project. Contact us below for a free consultation with our CEO.
Projects start at $50,000.
An interpreted high-level programming language great for general purpose programming.
A server side programming language known for its ease of use and speed of development.
View a sampling of our work implemented using a variety of our favorite technologies.
View projects implemented using this high-level programming language great for general purpose programming.
View projects implemented using this framework that allows rapid development of native Android and IOS apps.
View projects implemented using this server side programming language known for its ease of use and speed of development.
Learn more about our current job openings and benefits of working at FSL.
Detailed reviews and feedback from past and current clients.
Detailed profiles for each member of our team.
Our step-by-step process for designing and developing new applications.
Get answers to the questions most frequently asked by new clients.
Learn more about FullStack Lab’s Mission, Vision, & Company Values.
A high level overview of FullStack Labs, who we are, and what we do.