Software development is unpredictable but people waste hours every week trying to guess how long tasks will take.
Estimation can provide confide...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Ben,
That is an interesting point of view regarding software estimation, thanks for that.
Actually, this topic becomes very controversial when you mixed software developers with managers, as it all depends on the point of view. From business perspective, software estimation are basic, from software development a estimation it's just that .. an estimation. So, I would recommend (if you haven't read it yet) "Software Estimation: Demystifying the Black Art" amzn.to/39SiAYW
Because... What is an estimation? What's the difference between an estimation, a commitment or target? Actually, that's the first chapter of the book, and the author provides with an example that most of software engineers have faced at some point: A manager asks for an estimate, when they are really looking for a commitment or a target.
So from my software engineer point of view I agree with your focus, but from companies point of view probably an estimate (or commitment or targtet) is mandatory. Therefore, I think a balance between both trends is mandatory.
What do you think? Do you agree?
Thanks for the feedback.
I think companies that try to plan too far ahead can't respond quickly and effectively to changing technology and markets. This might or might not impact them.
I think we should focus on prioritisation and delivery over estimation and planning. We don't need to worry about planning if we are sure we are working effectively on the most important thing.
Now you're talking more the language of LEAN agile practices of which I'm engaging with more nowadays. Throw out waste, work on the most important thing, be confident in the next week and less so in following weeks, and go through predictable cycles of planning for things a month out and for this quarter.
Planning anything beyond this quarter will change a ton. Beyond 2 quarters is just business prioritisation/roadmap planning of what to engage in after resources finish up current projects.
Very thought provoking! It seems to be that the managers have to be agile trained in order for this to be facilitated smoothly throughout?
// not speaking from experience, never been in a full agile team
Totally agree. I try to push for no estimates wherever I am, and refuse to do them if asked. I've never seen any benefit in them at all... they usually just lead to: broken promises, rushed work, massive over-estimates to avoid missed deadlines, and generally a bad atmosphere.
Estimations have no value for development; they are a necessity of management in order to be able to plan. However, neither an estimation nor a plan ever survived the battle with reality.
The main reason is that estimations are one-dimensional, while reality knows the dimensions known effort, unknown effort (risk) and external dependencies. Only the first dimension can be estimated to near precision with enough experience, everything else is guesswork.
Completely agree with the points that only repeatable things become predictable, and thus should be automated - this is the 'lean' production engineering mantra 😁
Trying to avoid predictions for creative work such as writing new software, or designing new artwork for a game, or architecting a new town.. requires a cultural shift for most organisations to accept that customer feedback matters, not meeting arbitrary deadlines.
Ron Jeffries (of agile fame) has written on this topic in the past (as have many others!): ronjeffries.com/xprog/articles/the...
I think the #noestimates mantra goes hand-in-hand with 'products not projects', and 'first make it effective, then make it efficient' - noting that creative work is always at the effective stage, since there is typically no follow on production process to optimise!
Accurate estimates are valuable to management. I don't think accurate estimates are feasible in good software engineering and a managers job is prioritization over planning.
Over a long career I came to the cynical conclusion that in many large organisations the primary job of a manager is to pass good news upwards.
I agree with this one. One thing to consider though, is that, for consulting companies, like the one I work at, we need to create bugets/cost estimations for certain developments. So estimating is kinda required, otherwise we don't know how much to charge them. But it's really difficult to calculate, so we usually double or even tripple our initial estimations, and even then we sometimes take longer to build.
Have been working on software for 30 years
Never seen an accurate estimator/estimation
Great 3 points algorithm
After 30 years, the best estimates come from a gut feeling. Intuition gets more accurate with experience but it's often hard to explain why you 'feel' it should be 3 months rather than 3 weeks.
The word automation is used a lot in this article but is never actually elaborated on. The only detail I could find is reusing code as a form of automation. What other forms of automation are you referring to?
Automation through code-reuse with packages and automation of processes through code and APIs. There should be a strong focus in reducing manual work to maximise the speed to deliver software.
Hello Ben,
Thank you for the read, was interesting and our team had similar thoughts on estimation as well! But one thing I currently am suffering from is a bad estimate could go wrong as an agency, clients that are not well versed with agile and old-fashioned would return any further discussion on planned timelines with only negativity.
Other than culling out such clients, what are some of the ways we can prevent this from happening? It is indeed unpleasant on both sides, let me know if anyone have a fair share of this!
Thanks :)
I don't think it there is an easy solution to change culture.
A good start would be to engage with clients in smaller pieces of work more frequently. So instead of a large contract, try delivering a smaller set of deliverables sooner with renewal to continue the work. That should reduce risk while still allowing for the same or better long term results.
This is the same way we implement continuous delivery but at the end of the day it relies on building trust and responsibility to make sure that we are providing value to customers.
Agreed, the past few companies I worked for wasted a considerable amount of time on story refinement and estimates. Their velocity was always really low compared to other projects I worked on. Personally I don't give a rats ass if the story I'm working on is 2 points or 5 points, I still have to do the work. From a management point of view it has no value either... What they really ask for is a global estimate: When can we go into production with this product.
Somehow people have convinced themselves that they can give a more accurate global estimate if they take the total amount points estimated for stories ( which get added onto constantly) and divide it by the teams velocity (that is never the same, due to people getting sick, holidays, devs having a bad day, massive stories that carried over from previous sprints...) Its utter madness really 😛
We estimate on perceived size and complexity using tshirt sizes (S...XL) or Fibonacci if the PM needs to do some analytics. Time estimates never work and put undue stress and anxiety on all involved.
What analytics would they be doing? I imagine it would be something to do with estimating how much work can get done in a sprint.
We'd do this for Weighted Shortest Job First - so asking a dev: "is this a much bigger job than that? Because if it is I'll rank the one you think is easier first", and of course, possibly never do the really really hard job as it might not be valuable enough. We don't really do this for sprints - just for epics/features etc.
We also insist that those putting a value on a thing also make T shirt sizes for the value.
I agree with many of the points you made.
To add on this:
Estimates are meant to give a prediction on the complexity of a task. Not how long it's going to take to complete the task. This is where, many times, my frustration has come from as a software engineer.
Just because a ticket is a 3-pointer, it still doesn't mean you'll complete it "faster".
Software engineering has often a level of unpredicatibility and unknown. And indeed, it's part of the job and your responsibility to Google/read/ask about what you don't know.
My interpretation of "I had done X before" means that I know 80% of the task. The remaining 20% needs to be figured out, and that 20% may or may not be easy to navigate.
Estimates are useful for management, because they want to know when they'll be able to release a money-making feature to customers. I find them pointless from the developer's point of view.
But, since software engineering is a lot about business, we have no other choice than caring about estimates and trying to give the best guess.
If you can't estimate with some degree of certainty, that you can often achieve within 10% of that estimate, you're not in a great environment. All my teams in the last 12 years have been able to do this. I've been in the industry for 22 years, and in the last 12 years, I'm referring to 10 teams in 3 different environments.
The reason you can't estimate is because your environment has not been set up for you to be able to do so. You need technical and architectural standards, an excellent team and support structure, a rock solid process that empowers you to decompose complex domains methodically and systematically, methods of implementing and addressing true domain complexity, and last and not least, the right people.
I work in digital health, we have crazy regulatory requirements and deal with super complex domains, and we consistently estimate to within 10% of our initial guestimate. These are multi-million dollar projects that run for 9-18 months to reach v1.0. They often continue well beyond this.
It's much, easier than you think. It's just that creating the environment that makes it possible is the hard part. This is about leadership and responsibility. I don't blame you for thinking it's a load of crap if you've not been empowered this way. What is sad is that it's the case more often than not, and that is not good. Not for you or your project sponsor or customer. What a shit-show.
A great leadership and an empowering environment won't make the task any less unpredictable. If it's the first time you do something, you can't put an estimate on it. Being able to make good estimates means your work isn't really creative. You can live your entire life selling the same thing, though. Which is ok by the way.
We certainly don’t do the same thing project to project, but we don’t introduce new tech or change our architectural preferences unnecessarily either. That then just leaves the domain, which is far more predictable if you can decompose it responsibly. The idea is to create an environment that eliminates most technical risk, leaving people to solve for the domain with a great process and support structure in place.
This leaves every project in an 80/20 state from really early on, where 80% is what we’re pretty certain we’ll be able to figure out without any real heavy risk. Risk is then buried in that 20%, which is what we’ll focus on very early on to identify and address. Honestly, it’s just a recipe that works and I know can be replicated anywhere. Unfortunately as I said, it’s just really rare to find environments like this. Which is nuts.
I think you make it too simple. You are forgetting some reasons for doing estimations. I understand, that it can be used wrongly, but usually you want at least to get an idea of how long something will take approximately and if you are doing it good with experience it actually can be precise.
It looks like you are describing it from the perspective from a developer and even for developers estimations can be a good thing. You maybe want to know, how long a project can take or would you not care about it taking 1 month or 1 year?
Estimation of work which you are doing for the first time leads to frustration and finally waste of time.
In the 16 years since I started in this industry, I've only worked in one place where estimation was even slightly accurate, and that was in 2006 at a place that did Extreme Programming and used a vague notion of story points (mostly inaccurate) and "ideal hours" for tasks which tended to be more meaningful but still not very useful.
Since then, I've worked in a few teams where management thought Fibonacci points estimation was a good idea. It never was, as far as I can tell. Planning poker invariably led to long debates that were unproductive and led to tension and frustration:
T-Shirt sizing sounds more promising but I've seen it used to map each size onto a time period (say 2 days for small, 5 for medium, 10 for large) which then feeds into a Gannt chart of predicted work sequencing and targets, which is dangerous, but if your management thinks in terms of "failure to meet targets" instead of "targets were incorrect", then you have problems either way.
On teams where we did detailed estimation and sprint planning, I've tried to gently point out that I've almost never seen any team actually finish a sprint because they always feel pressured to load it with more and more tasks, making bigger commitments to avoid being seen as bad team players. This isn't their fault, but rather a natural consequence of detailed estimation and sprint planning. However I've rarely made the argument successfully and at least once suffered for trying to make the case. Sometimes there is an almost religious commitment to a particular model of "Agile" which is definitely not agile.
Speaking of the pressure to commit and deliver based on uninformed predictions, I've also spoken to good devs who got bad performance reviews from their manager because it took them 4 days to do a task that had only been estimated 1 point by the team. Imagine how unfair that would feel, and the negative effects it would have on morale and trust.
There was only one benefit I've seen from estimation, and that's simply thinking and talking about tasks with the team. Someone would often raise a really important point that saves us wasted effort later.
If teams would just spend a few minutes discussing upcoming work, looking for gotchas or proposing an approach to difficult problems, then THROW AWAY any estimates, they might get more value and less pain from the whole thing. Also, throw away your sprint board and try Kanban for the same reason. Sprints don't really work and they just lead to a regular feeling that the team has failed to meet targets.
I think this is a false dichotomy. Not all work that you can estimate can be automated.
Case in point:
If I was given a new project to work on with requirements and mockups that have been fine-tuned through deliberation, then I would immediately break down the entire project in terms of stories.
Then, I would verify the project breakdown with co-workers and get story points estimated for every story, making any adjustments as needed through this collaborative process.
By the end, I'll have an entire project represented in story points. Using either a sensible average velocity of the team on a previous project or a gut estimate of a velocity, you can pretty accurrately predict the length of a project, providing some padding for a low and high estimate.
Now, a project to, let's say, integrate a UI based on some mockups with new APIs that are being built cannot be automated--otherwise, our jobs wouldn't exist.
Is the estimate going to be perfect? Not always, but I have found the process I have described to get you very close. If it's off, was it a waste of time? By no means! We would have an accurate roadmap of the work that needs to be done, and often, the generated stories will have included valuable implementation hints/pointers by having gone through the process. It also helps set an appropriate expectation for the team even if it can flex.
Upfront detailed breakdowns rarely, if ever, reflect the reality of how things go - and TBH are about as futile as estimates. Thought processes change, approaches change, requirements change, simpler solutions are identified, etc. Only extremely high level breakdowns serve any kind of purpose in my experience.
Development (as opposed to simple ’building') is a very organic process, and should be allowed to proceed as such.
I agree. What I'm saying is it's you're not stuck between no estimates and a perfect crystal-ball vision of the project.
A detailed breakdown will give you a more accurate picture than no breakdown at all, even if things change as time goes on.
I have a lot of problems with this.
Some not automatable work is estimatable. For example an investigation into a software behaviour. If you do it enough you can estimate it. But you can't automate it.
Another example is the research for choosing a third party library , you can estimate that but you can't automate it. Also for some work, for example adding a new report or endpoint there are many aspect of that work that are the same each time you do it, like making a test plan, writing the documentation, security testing, performance testing. There are parts of the work that have higher confidence values and can set a "minimum time" for a peice of word.
Also there is some work that's automatable but 1. It doesn't happen often enough to warrant the work. 2. It's is critical enough or risky enough that code error handling is requisite but makes the work large.
In the case of number 2. You should probably get an SOP, standard operating process , for the manual work and then consider automation.
I also think there is some valuable organizational self discovery that can happen when you make estimates. Often organizations want the value good estimates can bring but don't want to the work of managment that process. The result is just bad morale.
Olympics runners don't just run many times and record how fast they finished the race. They collect all sorts of data, they reflect, they ask questions, they experiment. Most leadership gives me "ain't no body got time for that shit" . And then try to foist blame on me about the estimate inaccuracies.
We use agile and story points in Jira but it's still not easy to have a 100% estimate on how long something will take. There could be blockers, environmental issues, colleagues who are on leave etc...
So many variables to take into account.
Can't agree more! This is what so many developers, including myself, unfortunately have to learn the hard way after years and years of practical experience when we are forced by so many dumb people flocked into this industry and forcing us to estimate the unpredictable. This is what is hardly stated in any literature but it is quite the opposite. The words of this article should be carved in stones and should be the first thing for so called "expert" to learn before they even get close to managing any software project. These words should be in the first page of all books about software technology. Actually I think there should more book written just about this topic with practical examples to make sure all of the dumb people clearly understand the concept of impossibility and wastefulness of these kind of bad practices in the industry. I have the same opinion about using so called "design patterns" as a similar dumb practice.
Agree, spending too much time in upfront estimation is waste of time, but then runtime estimation is required to be in sync with other stack holders.
Apart from some repeatable identical work, we developer have tendency to experiment with different way of implementation, trying small things to optimize better, that’s where tasks take much longer time than estimation;
In addition, technology changing every day, identical task, which used to work earlier may not work the same way in newer version for next release, that also increase the delivery time line.
As a delivery manager, we must think hard, how much time we should spend on estimation (knowing that this time will be waste at the end)
Ultimate value is a function of gross returns minus total costs. (Net = gross - cost)
If we have no concept of cost, how do we know what the most valuable thing is? Actually, you are estimating, you're just doing it silently; which guarantees you'll have worse estimates than an explicit estimate (which I agree with you are often terrible)
I can provide 100% accurate estimates, as long as I can provide them in arrears of after having done the work.
I can meet any deadline my boss sets for me, as long as the software doesn't have to work properly.
Jesting aside...
For the actual work, I look at things as "small, medium, or big". And then for the small bucket, I divvy them up as "smallest (1), smaller (2), small (3)". The medium bucket as "smaller medium (5), average medium (8), larger medium (13)". The big bucket as "big (20), bigger (40), biggest (100)".
The pseudo-fibonacci numbers in parens are what I enter for the story points in Jira. It's just used by the PM to order things when factoring in the "effort" guesstimate. The PM doesn't calculate or use velocity, but that would be another possible use case.
We all like to work without a rush. But every project has a budget.
If a developer is not asked about the estimation:
As practice shows that time&material approach is better anyway, because customers always do not know what they want. But anyway some planning is necessary (hello to Sprints).
Most of the time managers do not need the precise estimation. They are working with bigger horizon. Often rough estimations like "2 months", "this quarter" would be enough.
Still my favourite piece on planning: secure.phabricator.com/w/planning/... see the "Maximizing Throughput" section.
It is incorrect with outsourcing project
Clint may not agree with this approach.