> Estimates are one of the hardest parts of software development.<p>And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on the really hard problems. Of course, it meant getting to know those developers and a prior (which we set at x2, for new starters).<p>Individuals were remarkably consistent in terms of their actual performance; so a x1 developer would almost always be a x1; a x1.5 would almost always be x1.5.
Author here. I've been lucky enough in my career to hold some senior positions, and I thought I'd give a step-by-step on an approach I took with an "enterprise-scale" software project, and how I stole some techniques from university project management courses to meet with some success. Happy to answer any questions :)
> you should expect to be held accountable if your estimates are too far off the mark because you failed to do your due diligence when coming up with them.<p>In a perfect world, I agree.<p>In the real world, which has a remarkable knack for failing to live up to expectations, what I find is that companies are rarely willing to allow the development team adequate time to do their due diligence. Answers, in and of themselves, are cheap. I can give you those all day. If you want to be able to hold me accountable for their accuracy, though, then you need to be looking at my <i>correct</i> answer rate sheet.<p>For me, the magic of #noestimates is the magic of open, honest cynicism. If my realistic options are silence and blowing smoke up my boss's ass, I'd really prefer it if they would allow me to choose silence. That way we can both keep our dignity.
This brings back memories from the days of my early career (an ex-PM survivor here). I would be curious to see some data, even anecdotal, on the success of this approach. Here's some interesting statistics from the industry (not specific to software, but you can extrapolate): <a href="http://apepm.co.uk/project-management-statistics/" rel="nofollow">http://apepm.co.uk/project-management-statistics/</a><p>In my view, traditional software project management is ineffective. I would put it somewhere between the Myers-Briggs personality test and modern day astrology.
- Projects only become official and tracked once someone has hacked together enough of a prototype to prove it works.<p>- at this point all project management is pretending it takes 100 managers to land something one girl / guy got flying.<p>- stop project managing, stop estimating, and just start treating companies as VC firms.
Hire good devs, make them care about your mission, invest in those that take off. Don't take the control away from the original devs
This is a great breakdown of your process. I've seen many quite like it and have also been asked to make these kinds of estimates myself on projects for many of the same reasons: someone made a promise to another person, signed a contract, planned a release date for something they just made up, etc.<p>What I find frustrating about the whole situation is that no matter what process you use for making these estimates you have a roughly 30-some-odd percent chance of being right. It almost never has anything to do with the process you used when it does go well. If it did estimating software projects would be trivial, wouldn't it? Everyone would use this process and we wouldn't have 60-some-odd-percent of large enterprise software projects going over time and budget.<p>In reality people have used this very process, I'm sure, and have been in the 60-some-odd-precent. People have been studying this phenomenon since before I was a nerdy kid hacking on my Amiga.<p>Having a roadmap or a <i>plan</i> to get from A to B is good. It will need to be readjusted as you explore the problem space and navigate the waters so to speak. But the only real guarantee we can make as engineers is that we'll make progress in my experience. I'm only giving really rough estimates in the beginning and those estimates improve as we get closer to our end goal. I only start talking about actual release dates when we get close to being finished and are mostly polishing out the rough corners and have already done a few iterations internally.<p>If someone makes a promise they can't keep or have no business making -- in my books -- that's their mistake and they've made it a problem for everyone else.
Great post. A key point you don't bring up is the aftermath, even if you do deliver. Especially in non-tech companies there still remains the tendency to view these projects as "done" after the end of the project/MVP etc., with no understanding that sites need ongoing maintenance and improvements. And that this work is still considerable.
> It also tells us how many team-weeks this fictional, idealised project would require [...] by adding all the estimates together.<p>I would be wary with just "adding all the estimates together". That's because we tend to estimate the median or the mode of the task duration, and not the average. Means can be added together, but not medians.
How to make developers want to hit their deadlines with quality? Startup land.<p>There was no feedback loop that rewarded developers to meet the estimates. Stock options weren't an option, and I didn't want them to do a sloppy job just to hit the 'deadline'.
The more projects like these I plan and execute, the more I find the need to account for external parties affecting timelines.<p>In the case of the author's payment system, say they go with a vendor. At that scale, there may be weeks of contract negotiations for fees, rates, minimums, etc. What if some piece of documentation is flawed and you need to have a back-and-forth with their support? What if they need time to onboard you into their systems?<p>It makes me appreciate Apple's supply chain mastery that allows them to deliver exactly on time because they own their whole process inside and out and demand similar rigor from any vendors that supply them. If we could imitate that in software, we could eliminate a huge source of uncertainty in many projects.
There are arguably two major phases here, and its only the second one that most folks here find controversial.<p>* Steps 0-2: determining "what" the project "is" (design, architecture, ontology)<p>* Steps 3-6: procuring and allocating resources to complete it (economics, management, politics)<p>It is tempting to decouple the two phases, and as a technologist focusing solely on architecture while leaving the economics up to leadership. However, social factors (the real people involved with the project) are an integral part of actually getting anything <i>done</i>, so I agree with the author's premise that the whole process should be viewed holistically (and ideally run by one technologist).
Seems like there's a structural issue at play here: the team is accountable for building a specific set of features at a specific time. High-level functionality is fixed and the timeline is fixed. If the estimate is off or something unexpected comes up, what's going to give?<p>Answer: everything else. Anything that the planners and executives didn't consider ahead of time. Other aspects of the work: code quality, product design, accessibility, performance, robustness, edge-case-handling... Team learning, culture and satisfaction. At the limit, the team will compromise on anything that you don't need to claim a feature is "done" with a reasonably straight face.<p>It's simply not a good system <i>even when the estimates work out reasonably well</i>—and, empirically, they usually don't.<p>To be fair, this isn't entirely the fault of estimates in general or this estimation approach in particular; I believe those contribute, but it's primarily a reflection of how the company and culture are structured. If you're already in a system like that and you can't change it, trying to do estimates well might be the best option forwards, but only because you're already in a corner.
I found it really fluctuates based on the team members. We definitely had 3x 4x differences in productivity between the worst and best on the team. Our estimates had to be good as it determined the size of the sales deal. Most everyone on the team was there for years, so we knew each other well. We could give a solid estimate but with a new team member is more challenging.
Call me crazy, but if we're going to call these goals, "estimates," they should actually be based on real data. Otherwise we're just making up numbers.<p>If the relevant data aren't tracked or stored anywhere, that kind of tells you how serious the org is about making accurate estimates.
<a href="https://rightingsoftware.org/" rel="nofollow">https://rightingsoftware.org/</a><p>"Based on first principles in software engineering and a comprehensive set of matching tools and techniques, Löwy’s methodology integrates system design and project design. First, he describes the primary area where many software architects fail and shows how to decompose a system into smaller building blocks or services, based on volatility. Next, he shows how to flow an effective project design from the system design; how to accurately calculate the project duration, cost, and risk; and how to devise multiple execution options."
Project management is hard. I wrote and won an SBIR award this year. A much different scale than the article, but I spent a lot of time writing the plan and budget and sourcing components and estimating software tasks. Two months in and a big chunk of that is out the window… haha. Finding connectors and other components has been a big source of pain, especially if purchasing in small quantities. Another example: I bought a consumable product which then immediately became unavailable… so do I try to make do with what I have on hand or make the decision to switch to a replacement?<p>Stressful, but I try to have fun. And extremely satisfying when things work out!
Doesn't this assume you have the "spec" before you start implementing it? But then how do you estimate how long it will take to come up with that spec?<p>If you have a very good detailed spec you have already done much of to work to make the implementation easy.<p>If the spec is high-level and "fuzzy" it leaves the work of "resolving the spec" to the programmer.<p>So trying to estimate the time it takes to code a system depends on the quality of the spec, and therefore is difficult if there is no standard on how detailed the spec is to be.
> Engineering does not work in a vacuum, and there are commercial contracts that will be signed, at a high level, without your involvement. Deals that will have been agreed before you joined the organization.<p>Indeed. And they’ll have been built on lies, damned lies and wishes.
I like how he says little-a agile - what most teams use. big-a Agile I reserve for specific Agile methodologies. Most companies aren't willing to invest in the rigor and effort for big-A Agile, and so you end up with this weird-ass hybrid.
From what I've seen the biggest problem is that the estimates are done as part of a sales cycle or to get approval to spend money of some sort.<p>Which is a different motivator to actually getting it done.
I would divide the projected total task in to 5 equal part and again each part in 5 equal part, and just worry about first of the first, after every part completion we can revise the target
Bullshit. You can make guesses about the future, but since that is going to inevitably change, it's a guess and can never be anything but a guess. At most companies, the scope is going to be radically expanded and looking too far in the future is a complete waste of time.<p>Other people in other fields are held accountable for deadlines because their work does not completely change and is not severely under-specified. If it is, then they are also just guessing.
I have to admit I popped a monocle when I saw the estimate for what is described as a rudimentary ecommerce website without even basic features like authentication and payment come down to 43 team-weeks, or in other words 12,040 team-hours. Even at one person per team being billed as $20/hr this works out to almost a quarter million dollars.<p>I understand the numbers are given as an example but I think the problem is that the scale of the task hardly justifies the complexity of the planning and using "teams" and "weeks" as sizes instead of "developers" and "hours/days".