Tasking developers with creating detailed estimates is a waste of time (2020)

At the end of the day, it doesn&#x27;t matter what process is used for coming up with estimates and delivering.<p>Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization&#x27;s reputation.<p>In non-dysfunctional organizations people at all levels can understand and adapt to curveballs that cause deadlines to slip. In such places you make estimates to the best of your ability with limited time and resources and communicate constantly with stakeholders on how things are going.<p>The hard thing is it all requires honesty.<p>Probably the most angry I ever got at work was once when, at the end of a project, I was on one of those bullshit status update conference calls with 20 people on the line. Throughout the project the team was I was on was led to believe that we were constantly behind and the deadline was from the beginning impossible to meet yet magically got pushed out several times to give us &quot;grace-time&quot;. We cut corners like mad-men, amassed insane levels of tech-debt, and all but put a midget in the machine to make it work. What happened on the call? The product management team congratulated the PM for delivering so far ahead of time. I was so angry I couldn&#x27;t even talk. Basically, the PM got accolades, the customer got shitty product, and we hated our jobs.

An estimate is usually the sum of a bunch of smaller estimates. Those estimates have a probability distribution that is asymmetric. While sometimes they can be quicker than anticipated, the lowest they can go is zero (turns out we don&#x27;t need it, cut it) and that kind of thing is relatively less common than a blowout the other way. Those blowouts are uncapped, while zero time is a minimum there&#x27;s no maximum. The unknown unknowns are the things that get you. Seems like it will take X but the frobnicator was broken in ways we couldn&#x27;t have anticipated so we had to get a different thing and then hack it to make it do what we actually needed etc etc. Each individual item has a low probability of that happening to some extent. When you have a bunch of things in sequence one of them probably will if not more.<p>IIRC each item is described by a poisson distribution. (Have I got that right, mean, long tail). Nobody models estimates as a sequence of dependent, poisson distributed events, that I&#x27;ve heard of at least. If you did you might at least get a range on the estimate. Between 2 and 20 days. That would be more accurate. Useful to anyone much? Unclear.

Years ago, when I was working at a company, I did a detailed estimate of a large project.<p>I broke it down into components and individual tasks, then put estimated hours against each one, then put it all into a giant spreadsheet, to track planned vs actual times.<p>If I remember rightly, it totalled about three months of elapsed work time. And it took me over a week to compile the estimate.<p>I also remember that I hit the predicted end date to within two days.<p>But the interesting bit was each individual task was inaccurate - lots were wildly underestimated, balanced by those which were wildly overestimated. Stuff like things I thought would take a day taking 15 minutes, other things I thought would take an hour taking a week.

&gt;There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.<p>I believe this has only happened to me once in my career. My employer had recently switched from flat rate project bids to time and materials. A data transformation project that looked like it would take five or six weeks turned out to have repetitive tasks that could be automated easily. My estimate of three days, which was already padded, wasn&#x27;t appreciated by the PM what wanted a month of revenue. After being told several times to account for contingencies and not budging much on my estimate, the project was taken from me and given to another engineer who gave the PM the estimate she wanted. While this was going on, I had already written the necessary code. My coworker had a month of mostly relaxed days as I turned the code over to him and he got busy finding ways to look like he was doing work for a month. Maybe I should have done that instead.

If you&#x27;re consulting, you absolutely need to have estimates -- because that constitutes the bulk of the Statement of Work (SOW), that is, the contract.<p>And if that estimate isn&#x27;t within 10-15% (the usual error bars) of the actual project duration&#x2F;billable hours, there&#x27;s going to be a problem.<p>What&#x27;s more, while the developer(s) involved should have some input into that SOW, they shouldn&#x27;t be <i>writing</i> that document. Rather, they should be writing code for other projects already estimated and sold.<p>As for in-house projects, that&#x27;s a whole different story and is really dependent upon the processes of that particular organization.<p>All that said, developers should be spending their time <i>developing</i>, and their managers&#x2F;managing consultants&#x2F;salespeople should be doing all the other non-development tasks.<p>Edit: Fixed grammatical errors.

The article was doing pretty well until they brought up historical data. The exact same software project done twice can take wildly different times because the team and&#x2F;or the requirements are different.<p>That&#x27;s the whole point of Agile, you need regular interaction with a customer to slowly build the software to a state they are happy with. And they should keep paying for the work until it is done or accept whatever state was delivered by the time the budget ran out.<p>If that is not how you are doing Agile you have missed the point. It is not possible to predict software development because unlike a bridge the requirements are never fixed and there are too many unknowns.<p>If you get your requirements fixed at the start, they never change, and you are not going to suddenly have to deal with some library&#x2F;framework change in the middle of everything, then you can estimate, but you are not doing the software development 99% of the world is.

I like doing detailed estimates, because it helps me decompose the problem. This gives me a chance to get a good understanding of the problem, and get up-front clarification from the customer on even the smallest details. The side benefit is that it also gives me an idea of how long the project will take, with regards to the knowns. Then I triple that as my estimate to cover the unknowns, with a bit of wiggle room to spare. Then I stick to my guns with management (a luxury, I&#x27;m aware), and the customer&#x27;s expectations generally get set accordingly. So, while it may not be an exact estimate, I have an accurate understanding of the requirements up front, and the customer usually ends up happy on the back end.

On my current project we don&#x27;t estimate. It might not be suitable for most projects but we just pick up tickets off the kanban board instead of wasting days every month arguing whether a ticket is a &#x27;5&#x27; or an &#x27;8&#x27; we just do the work that needs doing the most.

An estimate is guess but is never treated that way.<p>Budgets are built on it, deliveries agreed. Doesn&#x27;t matter how much you decompose the task - unless you&#x27;ve coded that exact same thing many times before in the same way under the same conditions then it&#x27;s just a guess. Been estimating for industry for about 20 years (although not the last 6 because we&#x27;re agile in the truest sense) and most of the estimates have been wrong - sometimes over, sometimes under. Tech estimates are a lie that loads buy into.

My God I remember the days of coming up with estimates for like 40 tasks, each a few days, say, then &quot;negotiating&quot; with sales&#x2F;PM where we could shave a day off here, a half day there.<p>And lo and behold, we price for a 30 day project that ends up taking 50...<p>So ridiculous.

&gt; For many of us a dearly loved date has already been selected, which makes our estimation efforts really interesting as we endeavor to shove more and more &quot;stuff&quot; into that bag.<p>The problem is not to ask for estimates, companies need to budget, plan hiring, and inform clients. The problem is that many companies do NOT ask for estimates but create delivery dates out of thin air.<p>So, I agree that estimates are a waste of time if they are not used. But they should be used as are part of any reasonable-managed engineering project.

I work with utility companies on multi year migration projects to move their entire tech stack. This includes, a different database, different data schema across thousands of tables, new front end components, desktop and mobile applications, multiple third party integrations and the training and documentation for the whole thing.<p>The utilities are heavily regulated, often beholden to taxpayers, lawmakers and public utility boards and working on use it or lose it budgets with hard cutoff times for delivery and go-live dates.<p>It&#x27;s not just budgets and time constraints that make it impossible to do flexible estimates. Their internal personnel all have their regular work duties to attend to while supporting the migration and they can&#x27;t drop everything for years at a time to dedicate support for the project. Add in the coordination with multiple vendors and you need to be hitting your time estimates, planned years in advance, within a week. Sometimes budgets don&#x27;t matter that much, once they are a year into a three year project, they will find the money if it&#x27;s needed, but the coordination alone requires this kind of accuracy.<p>It&#x27;s amazing what necessity does to your estimates. We have become really good at it. This includes things like &quot;Oh we&#x27;re working with Oracle, add 3 weeks to that integration just because&quot; or &quot;this is a mobile app for the service techs who tend to be resistant to change, add another week for training and a month for revisions&quot;. Yes this is just &quot;padding&quot; but it&#x27;s very specific padding that&#x27;s tailored to the type of work being done and has so far been accurate and continually getting better for us.<p>edit: I should add that our estimation process involves multiple week long workshops with all parties. We go over every tool, process, integration and technology currently in use and then write a detailed design document that goes through 2 rounds of review with the customer before being signed off on. These design documents become the basis for a secondary contract to do the actual work and the customer understands that if it&#x27;s not in the document, it&#x27;s not getting built or migrated. Any additions require a contract change order.

Just do an aproximate estimate, multiply by two, and add 30% ... it won&#x27;t be enough anyway.

Decomposing projects before you even start coding is everything.<p>The bigger the project, the more likely it is that some small thing - something in the original spec, maybe, or more likely, an unforeseen interaction of its pieces - will be missed and will take an inordinate amount of time to deal with. All it takes is one of these to thwart the entire estimate.

Going too deep on any estimate is actually a bit of a pitfall. We see this in my world (large scale project management) where some folks want to plan activities down to the tiniest tiniest level, and it just doesn&#x27;t pay off.<p>In software, it&#x27;s hard to do estimates at all if you&#x27;re a blue-sky environment. Once you have a codebase you&#x27;re working on, it can be possible to give a better estimate of what it will take to implement a new feature, but the more elaborate the feature, the softer the estimate.<p>We have just shipped a very big change to our product, and we thought it would be a 3-6 month effort to do so. It took 3 years, because it was VERY invasive and VERY complex, and we just didn&#x27;t understand the underlying challenges enough when we set out to do it.

&gt; an agreed upon estimate<p>That&#x27;s not an estimate; that sounds like the outcome of a negotiation. If someone demands an estimate from me, they get one - if it&#x27;s not the one the manager wanted, he&#x27;s free to substitute his own.<p>I&#x27;m accustomed to managers upping my estimates by 10%, and I&#x27;ve known them to increase them by 100%. For small jobs, requiring an estimate instantly doubles the estimate, because it takes longer to produce a good estimate than it does to do the work.<p>If you reduce my estimate, or try to talk me down, the new estimate is your estimate, not mine. And if you think it&#x27;s fair to try to nail me to my estimate, then you obviously don&#x27;t know what &quot;estimate&quot; means, and I need a new employer.

The article jumps from detailed hour-driven estimates, to just duking it out. Why does everything have to be so black or white? Why does it have to jump from hour-level to prophecy?<p>Here is what works at a project level:<p>* When estimating, never go any step beyond the Feature level (don&#x27;t split tasks, most of the time not even stories – just Epics or milestones are enough)<p>* Do RELATIVE COMPLEXITY estimate. Not time. If &lt;epic1&gt; is a medium, then relative to it, is &lt;epic2&gt; large or small? Stop at that level. Don&#x27;t split it down any further.<p>Now compare just one of the epics to past history. That&#x27;s all you need to estimate the rest of the scope, as it&#x27;s all relative. It takes not more than a few hours for due diligence.

A co-worker of mine had a good idea: require management to seal within an envelope the cutoff value that would determine the outcome the decision that required the estimate (e.g. Estimate &gt; X then Do A and Estimate &lt; X then Do B). When the estimate comes back open the envelope.<p>So often, management wants a certain outcome, but needs the estimates as cover for making the decision. Just demand a detailed estimate, fool around with the estimates details--no matter what the estimate ends up being, and finally say &quot;Estimates indicate that we should do this.&quot;, which is what they wanted to say all along.

I&#x27;ve tried to get into the following routine for my team:<p>1. A daily standup bot pings us with the tickets assigned to us. We respond with a gut-level &quot;percent complete&quot; number for each ticket.<p>2. The bot tracks these estimates and over time, each team member can see whether they tend to over or under estimate.<p>The point is that we don&#x27;t try to cram accuracy into developers, we just let them guess and let them see over time how good they are at gut-level estimation. The hope is that they&#x27;ll eventually improve their estimations, but we&#x27;re not going to tie it to performance or anything.

After a couple decades working at companies and projects of all sizes, I always cringe when I hear prescriptive ideas about some abstract approach working or not working. In my experience, lots of different things <i>can</i> work, but there are more ways to fail than to succeed. When we&#x27;re talking about large scale software projects with fluid requirements ultimately success hinges primarily on having competent individuals and trust between them.<p>Without trust everyone is trying to cover their own ass, and in the case of large projects most of them will easily succeed since you only need one scapegoat. This is the type of environment where detailed estimates are demanded so that management had a paper trail, or where engineers implement the letter of a PRD and never propose changes to inconsistent or awkward requirements because it&#x27;s too much energy and they&#x27;ll be gone before they have to deal with the tech debt anyway. Often times in these type of environments someone will propose a process such as scrum to address particular pain points, but layering a process on a dysfunctional team doesn&#x27;t address the core issue; at best the routine can shield individuals from chaos, but it won&#x27;t actually improve throughput in any meaningful way.<p>At the end of the day, the best you can do with large scale estimation is get a handful of your best engineers who can roughly envision what needs to happen and have them chalk out a rough plan at a very coarse granularity and with key assumptions enumerated. Then with your best product people chalk out a strategic roadmap showing where they believe the product should go over the next 5 years so they can take that as input into account for architectural strategy. The key thing is that everyone understands that all long-term plans are subject to unknowns and change for all sorts of reasons—the point is not to pin people down but to leverage individual expertise to develop a best guess at what is possible. This is where trust is at its most tenuous and stands on a razor&#x27;s edge; all it takes is one bozo to treat these things as guarantees and start throwing people under the bus when things go wrong, and before you know it trust is gone and everyone is in cover-your-ass mode. Now the group has lost the ability to accomplish the most ambitious goal of which they would otherwise be capable.

Estimates for tasks&#x2F;apps&#x2F;games&#x2F;projects that have been done before, or known from previous work are usually pretty close. Like for instance making another version of a puzzle game with changed assets and maybe a few new features.<p>Estimates for tasks&#x2F;apps&#x2F;games&#x2F;projects that have NOT been done before, or known from previous work are usually wildly incorrect. Like for instance making the first version of a puzzle game with new everything. Even more so for a new game type that you haven&#x27;t done before.<p>Software estimation is like 65% correct (2&#x2F;3rd) usually. There are so many internal, external and just unknown areas that usually these are underestimated greatly. The estimation is off by more when there are third parties or components&#x2F;frameworks that get you 90% of the way but make the last 10% more tasking than custom sometimes.<p>The nature of software design and development is usually creating new value, in that case lots of those projects are unknown or the first time through something, estimation is almost useless in those areas. It is better to do prototypes to help refine and break it up into parts that can better be estimated.<p>Anyone doing an estimate on a new area that hasn&#x27;t had a prototype will always be wrong. Estimates more than a month out are also wildly wrong. When you are asked to estimate something big, always just do an estimate for a prototype first before you ever begin to try to estimate the rest.

This appears to be based on a strange assumption that developers&#x27; estimates can&#x27;t take historical work into account, but dev managers&#x27; can; and that estimates coming from dev managers and based on historical work will not be questioned for being too high even in orgs where the devs&#x27; estimates will.<p>I&#x27;m not sure the prescription given fits the disease described; it feels more like passing the problem on to a different role than actually changing the approach.

To me, detailed estimates can make sense if you&#x27;re working in a factory&#x2F;conveyor-belt environment - where the products are very similar, and you (the company) has shipped hundreds to thousands of such products.<p>At least then you should have some data to look at - but when it comes to boutique products, with new clients, new teams, etc. who knows - you could easily get stuck on something for weeks to months, with no obvious resolution.

In my essay &quot;The worst project manager ever&quot; I talk about some of these same flaws, but I also talk about the best project manager that I ever worked with, Sonia Bramwell, and I recount some of the lessons she taught me about great project management:<p><a href="http:&#x2F;&#x2F;www.smashcompany.com&#x2F;business&#x2F;the-worst-project-manager-ever" rel="nofollow">http:&#x2F;&#x2F;www.smashcompany.com&#x2F;business&#x2F;the-worst-project-manag...</a><p>About this:<p>&gt;There is back-and-forth as the estimates are questioned for being too high, almost never for being too low.<p>Sonia did not allow us (the engineers) to talk to upper management, so she handled the translation herself. In some cases she was worried about macho engineers who competed on how fast they could do something:<p>&quot;I can do that in a day&quot;<p>&quot;Oh yeah? Well, I can do that in 4 hours!&quot;<p>&quot;Ha! You two suck! I can do it in 2 hours!&quot;<p>Perhaps Sonia&#x27;s greatest ability was to figure out exactly how much each engineer tended to overestimate or underestimate tasks, and then to weight their answers accordingly. For the upper leadership, she was the only one who continuously offered accurate estimates of how long big new features would take.

&quot;What a useful thing a pocket-map is!&quot; I remarked.<p>&quot;That&#x27;s another thing we&#x27;ve learned from your Nation,&quot; said Mein Herr, &quot;map-making. But we&#x27;ve carried it much further than you. What do you consider the largest map that would be really useful?&quot;<p>&quot;About six inches to the mile.&quot;<p>&quot;Only six inches!&quot; exclaimed Mein Herr. &quot;We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all ! We actually made a map of the country, on the scale of a mile to the mile!&quot;<p>&quot;Have you used it much?&quot; I enquired.<p>&quot;It has never been spread out, yet,&quot; said Mein Herr: &quot;the farmers objected: they said it would cover the whole country, and shut out the sunlight ! So we now use the country itself, as its own map, and I assure you it does nearly as well.&quot;<p>from Lewis Carroll, Sylvie and Bruno Concluded, Chapter XI, London, 1895<p>from Wikipedia: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;On_Exactitude_in_Science#Influences_and_legacy" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;On_Exactitude_in_Science#Influ...</a>

When I was working at a big online travel site, we used to have a requirements document template which started with a &quot;flexibility matrix&quot;. It was a two-by-two grid with &quot;scope&quot; and &quot;date&quot; along the y-axis and &quot;most flexible&quot; and &quot;least flexible&quot; along the x-axis. The stakeholders were supposed to indicate to us whether the scope or the date was &quot;flexible&quot;. Of course, we got an unending series of requirements where the date was &quot;least flexible&quot; and the scope was &quot;most flexible&quot;, never ever ever the other way around.<p>It got to the point of such ridiculousness that we finally started trying to flex the scope because the dates were so unrealistic.<p>Management&#x27;s response? Add another row and column in the matrix of &quot;resources&quot; (that is, it&#x27;s ok to add people if you need to) and &quot;somewhat flexible&quot;. So after that all of our requirements were &quot;date least flexible&quot;, &quot;scope somewhat flexible&quot; and &quot;resources most flexible&quot;.

I recently left a company that had settled on using monte carlo estimation - ignore the ticket sizes and monitor the spread of ticket estimates in order to provide a % estimate to management about when something could be expected.<p>It was pretty crushing to have to constantly explain that my tickets were bigger than the average to a guy who obviously only cared about getting his KPIs down. I left.

Among other things, Extreme Programming says that estimates increasingly diverge from reality if they&#x27;re longer than three weeks. So: Do you need <i>accurate</i> estimates? Then you need detail. The fuzzier the estimates can be, the less detail you need.<p>Do you need developers to do the detailed estimates? Yes, for two reasons. Politically&#x2F;socially&#x2F;culturally, having someone else telling you how long something is going to take you to do is... not received well, given normal human nature. Functionally, the developers have to be the ones to do the detailed estimates, because they&#x27;re the ones who actually <i>know what the details are</i>.<p>All that said... <i>overly</i> detailed estimates are a waste of time. Don&#x27;t break it down into a series of tasks, each of which take one hour or one day.

&gt;&gt; ?+?+?+Contingency™=The Date™.<p>I&#x27;ve always had a strong feeling that my strong feeling about when something will be done is fairly accurate. Decomposing that into ?+?+?+Contingency for the client tends to be the hard part.

I learned very early on in my career that the right way to do estimates is to do multiple estimates and cross-check them. If you have multiple estimates using different methodologies and they all are fairly close then you know you have a good estimate.<p>Time estimates are still useful even if the range is large. If a high-bound estimate is still acceptable - great, ship it. If a low-bound estimate is barely good enough, that is a huge risk. If you get multiple estimates from multiple developers and they are wildly different, there&#x27;s a conversation (i.e planning poker)

It depends on the developers process of coming up with the estimates. If they&#x27;re breaking down the tasks, thinking of all the things that can go wrong and factoring in contingencies, sequencing them understanding dependencies, and work other than delivering code, data migrations, support, monitoring, and so on, the estimate could be thrown out without anyone ever looking at it but the developers would have a much better understanding of the project and a good sketch of a plan of attack to make the time making the estimate all worthwhile.

The iron rule is the person doing the work also supplies the estimates, which are the only ones with any chance of getting them right. This article seems the developers have not been properly trained on how to give accurate estimates.<p><a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2007&#x2F;10&#x2F;26&#x2F;evidence-based-scheduling&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2007&#x2F;10&#x2F;26&#x2F;evidence-based-sch...</a>

Estimates are mostly wrong. Retrospectives always have hard data. Many projects seem not to have the time for retrospectives. There are few other places in project management overheads to look to find the time for retrospectives. Cut the time for estimation, and reduce the focus on them. If you use retrospectives well, you may find you do not need to spend that much time on estimates, and even further reduce the use of estimates.

I think this article misses the point. Estimation should never be a goal. It should merely a tool that helps with identifying risks early on and that helps with identifying the &quot;minimum viable product (MVP)&quot;. The term MVP was never mentioned in this article and I don&#x27;t see how you can have a serious discussion about project estimation and dismiss the benefits of agile without even mentioning the term MVP...

It&#x27;s surprising that developers and business people still haven&#x27;t found a way to come together on this stuff and explain to each other why our views on estimates don&#x27;t line up.<p>At the end of the day a business is always going to need some sort of idea of what&#x27;s being built and when it might be ready so that they can get a rough schedule together. No matter what games developers and project managers play with story points, or t-shirt sizes, or the myriad of other coping strategies they come up with, someone in the chain is going to try and map those to time scales.<p>In my experience, a reasonably senior developer can give a rough estimate of how long something is going to take in any case that isn&#x27;t a complete unknown, if they really can&#x27;t then you need an investigation project and that can be given a set time. But for almost everything else you can roughly say if it&#x27;s an hour, or a day, or a week, or month. As long as everyone accepts that sometimes that will be over, and sometime under. If its an hour that doesn&#x27;t mean you can do eight of them in a work day, but it means you can prioritise work.<p>That&#x27;s the key I think, if you have a fixed date or a fairly fixed date, then it&#x27;s often a good constraint. What you need to do is prioritise the work, and the only way you can do that is if you know that the things in your list could reasonably be done in that time. You can&#x27;t have no estimates, and task three means your entire team needs to invent an AI or something stupid that will burn the whole timeline down.<p>If you&#x27;ve put a rough estimate of a week on something and you&#x27;re reaching the end of week two, it&#x27;s a great time to reassess. What technical people often don&#x27;t get told, or don&#x27;t understand is that sometimes something is only valuable if it can be done in a certain time. The business might want a feature that could be done in a week, but have no interest in it if it&#x27;ll take six months.<p>If both sides can admit to their fears then it shouldn&#x27;t really be too complex. Business is scared you&#x27;ll get to the deadline and have 20% of the work done, with a good prioritised list they&#x27;ll probably be happy if you&#x27;re 80% of the way there. Developers are scared you&#x27;ll hold it over them and berate them if their one day estimate becomes two days, but they probably know their one week estimate is bullshit and they just want to cover their ass a bit.

Discussing about the effort required for each task&#x2F;story, is crucial to generate alignment within a team, determine better the scope of a task&#x2F;story -- and decompose it, if it appears that the effort would be so big that tracking what has been done and what remains to be done would be intractable.<p>The by-product of these discussion may be summed up as a number. But oh yes its unit must not be time.

I think it&#x27;s fun to read all the stuff about how it is impossible to estimate what software costs.<p>What is so magically different about it? All other professions can do it. And not just the other professions, our company is one of many software shops that sells projects. We need to be able to make good estimations to be profitable, and we are.<p>Maybe it&#x27;s all the VC and BigCorp money that is stopping you.

It depends on how they estimate and how familiar they are with the code base. I know developers that have been nearly spot on consistently with modifications and maintenance work.<p>The wildly inaccurate stuff seems to come from new work with loose definitions, manic developers, or situations where the work is billable hourly and outsourced.<p>Sometimes it&#x27;s good to have an old, graybeard developer on the team :).

Simple question: Why are deadlines needed?

Only tangentially related but, for project proposals and planning, my favorite exercise is the Heilmeier Catechism: <a href="https:&#x2F;&#x2F;www.darpa.mil&#x2F;work-with-us&#x2F;heilmeier-catechism" rel="nofollow">https:&#x2F;&#x2F;www.darpa.mil&#x2F;work-with-us&#x2F;heilmeier-catechism</a>

<a href="https:&#x2F;&#x2F;medium.com&#x2F;@zack_98398&#x2F;is-reading-articles-about-whether-making-detailed-estimates-a-waste-of-time-a-waste-of-time-6c9a5439a7ea" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@zack_98398&#x2F;is-reading-articles-about-whe...</a>

&gt; I said a 8 but I don’t really know why &gt; Could be a 1 or it could take my whole life<p>those lines made me laugh out loud the first time I heard them<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=sh7A8UChBTI" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=sh7A8UChBTI</a>

Agreed completely. My detailed write up here fwiw.<p><a href="https:&#x2F;&#x2F;www.brightball.com&#x2F;articles&#x2F;reality-driven-development-fixing-project-management-in-software" rel="nofollow">https:&#x2F;&#x2F;www.brightball.com&#x2F;articles&#x2F;reality-driven-developme...</a>

Estimates are just something (bad) management can use to point the finger and assign blame.<p>As long as the middle ground between rough-as-toast and perfection is found when developing something, and that something is delivered, then it takes as long as it takes and that&#x27;s that.

I don’t think creating detailed estimates is a waste of time. Planning brings clarity to engineering.<p>However, PMs weaponize estimates against the engineers and that ruins the whole exercise.<p>Also, teams should use a betting market with real money. People deserve to be paid extra for being right.

Better to deliver incremental evolutionary value, so that the business side gets useful feedback iterations on what engineering can deliver. This allows the company as a whole to iterate its customer relationship.

Civil engineers come up with estimates for time and cost to complete projects or upgrades. These estimates are contractually agreed with provisions for delays and overruns. Developers are not doing engineering work?

earlier in my career, I would have said that, yes, it is a waste of time.<p>on one hand, estimating essentially requires architecting, and that&#x27;s never a waste of time. on the other hand, you could argue that even w a good plan you won&#x27;t know where the 1-2 rabbit holes will be (some subtly critical facet of my use case not jiving with the proposed toolset).<p>So i&#x27;d say get a decent plan (weeks, not hours) in place and give yourself a 50%+ buffer.

Tasking developers with anything other than developing, thinking or talking about thinking and developing is most certainly a waste of time.

Hours typically track money and velocity. These are different things. So book developers per week and use story points for velocity.

What&#x27;s the best way to start changing company culture like this?

Yeah, but how much time will it waste?

For myself, I have found that the more detailed an estimate, the more detailed an &quot;up front&quot; plan. This is a classic pattern, and techniques like Waterfall and TDD rely on it. It&#x27;s an extremely good way to get the costs and plan formalized (critical, in many organizations). Further, with TDD, this allows a very detailed and complete test matrix to be established, so the end quality can be quite high.<p>I worked this way for most of my career. One of the big reasons, is that I spent a lot of my career, writing software in support of hardware devices, and coordinating parallel development efforts was crucial. Lots of critical paths.<p>Also, hardware people tend to be <i>very</i> &quot;waterfall-y,&quot; so I was often never given a choice.<p>As a result, we learned to give fairly accurate estimates, for pretty long-term projects.<p>The main problem with this approach, is that it delivers yesterday&#x27;s technology, tomorrow. By the time the project is released, no one wants it. Also, it&#x27;s quite possible to deliver features and algorithms that aren&#x27;t useful, inherently flawed, or actually detrimental to the user&#x27;s workflow.<p>Once it has been written into the lists, it is set in stone; even if it is found to be a mistake.<p>After leaving my last job, I started experimenting with more flexible development methodologies. I think I&#x27;ve had some success[0]-[4], but the scope of the projects has been <i>much</i> more humble than my previous works (out of necessity).<p>In the project that I&#x27;m developing now, there has been almost no &quot;up front&quot; plan at all, and no set schedule. I&#x27;ve been working on the frontend app (a native Swift iOS app) for over a year. The backend is a couple of servers that I wrote years ago. One has since become a standalone open-source initiative, run by a different team[5], and the other was one that I made as &quot;practice,&quot; several years ago[6].<p>In developing the frontend, I created a TestFlight-ready app, almost immediately (I made my first TestFlight release about a month after I started coding). This has been a &quot;running prototype,&quot; ever since. The entire team gets releases, quite quickly, and gives feedback and testing. Additionally, the app is continuously being vetted by Apple, so we are unlikely to have the &quot;App Store Approval Brick Wall&quot; problem.<p>This has allowed the specification to &quot;morph,&quot; throughout the life of the project. I have actually thrown away months&#x27; worth of code, as we have decided to pivot direction, many times, throughout the lifecycle.<p>We&#x27;re all <i>very</i> happy with where it&#x27;s at, now. We are in the home stretch (but we still have at least a couple more months of work on the frontend app). It is almost entirely different from the original, unworkable, &quot;idea man&quot; concepts, that were presented to me, over a year ago.<p>I&#x27;ve also been doing this for free. I can&#x27;t imagine any company that wanted to make money, doing it this way. I would have been forced to deliver a crap hack, six months ago.<p>[0] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;thats-not-what-ships-are-built-for&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;thats-not-what-ships...</a><p>[1] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;forensic-design-documentation" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;miscellany&#x2F;forensic-design-docu...</a><p>[2] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;evolutionary-design-specification&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;evolutionary-design-spe...</a><p>[3] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;concrete-galoshes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;concrete-galoshes&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;testing-harness-vs-unit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;littlegreenviper.com&#x2F;various&#x2F;testing-harness-vs-unit...</a><p>[5] <a href="https:&#x2F;&#x2F;bmlt.app" rel="nofollow">https:&#x2F;&#x2F;bmlt.app</a><p>[6] <a href="https:&#x2F;&#x2F;riftvalleysoftware.com&#x2F;work&#x2F;open-source-projects&#x2F;#baobab" rel="nofollow">https:&#x2F;&#x2F;riftvalleysoftware.com&#x2F;work&#x2F;open-source-projects&#x2F;#ba...</a>