About 10 years ago, I worked on a large, multi team (multi-org really) project that was run using TOC (Theory Of Constraints). Put very very very simply, every team was told to give honest, buffer-less estimates for their primary work areas, and then a global project buffer was added as a factor of the sum of estimates.
At any point in time, we worked as if every single thing would line up perfectly, so upcoming milestone targets would often feel crazy or unlikely. But people being eager to please, and mostly unwillingness to be the one team blocking the entire project - meant that folks worked hard to meet some of these targets.
It was extremely hard. It was a bit stressful. It felt crazy at times. But it got done in half the time I would have initially expected such a complex project to take.
To me, the most impressive thing about it all was that the project leader drove us all quite hard but was super cool - he explained that he wanted everyone to be open and honest about blockers so they could be moved with the full force he was given, and that actually, his way of measuring project progress was the rate at which schedules slipped.
That's wild. I've always wanted to see what projects managed with all the leadership buying into ToC or Reinertsen's Principles of Product Development Flow would look like.
As an engineer I've experienced dumb deadlines, but I've equally seen wasteful decisions by engineers that are at best resume padding and often legitimately harmful to product and code quality ("let's make this a microservice" lol).
My favorite is when leadership wants something dumb or contrary to reality and engineering teams are happy to build it because they can use fancy technology. Then when the product is delivered late, a little buggy, and users don't actually use it anyway — everyone can shrug, point to someone else as at fault, then rinse and repeat the game. Incentivizing honesty is hard.
After trying to fight very hard against leadership that wanted to build something contrary to reality and burning out I have decided to never fight again. I'll build it, no questions asked, and I'll relish in wrecking the company as I build it. It's the only way for me to stay sane and enjoy this industry anymore.
Every deadline can be met if employees are "eager to please" and will work unlimited overtime hours for free. What estimation theory you use doesn't really change that. The true challenge of project management is – can you set realistic deadlines and meet them assuming a normal workforce with normal priorities putting in the standard amount of effort towards the job.
Things would change if overtime was paid at a mandatory 1.5x and 2.0x. The true cost is always hidden because people "eager to please" work overtime for free (or for a slice of pizza).
That's not really true. There could be not enough hours in the day, even with lots of overtime, and your team could have an impossible task. Eager to please employees will still clock the overtime, because then "at least I tried", and they have the optics of "giving their all".
However, I agree with your overall point. Getting things done on time without abusing people (I consider using people's personal time to be abusive), with everything in harmony is hard.
It's easy to push your employees to log hours and have everything be a trainwreck when people are cranky, overworked, and cut corners to make deadlines.
> Every deadline can be met if employees are "eager to
> please" and will work unlimited overtime hours for free.
No amount of pressure or willpower can get software done if the team is badly aligned, working on the wrong problem or simply flailing. The message I take from the parent post is not about estimation theory, it's that the project manager created a delivery culture across a large team.
Did you like the outcome and did it feel sustainable?
I'm so conditioned to providing buffered estimates, especially for highly-dependent systems, I would really struggle to not accidentally buffer. I'm generally invisibly factoring in organizational dependencies (e.g. Bob will need to stand up service X, but Aditya's approval of that will be subject ridiculous process Q that always takes two weeks). It sounds like this would invert the dependency tree if broken down well enough.
Cynically, I struggle to imagine working in such a high-trust environment that wouldn't immediately be destroyed.
What does an honest, buffer-less estimate mean? Is it the number of person-hours to make you 50 % sure the task is completed? Or 90 %? Or something else?
For planning on film sets I would use the "this is how long it would normally take to do X if you do it at a normal tempo and no unforseen blockers appear".
For these you add the buffer. Sets that I scheduled were most of the time slightly faster than the schedule, until a blocker appeared which ate the buffer, but was usually resolved without eating it away completely. So at the end of a day we were always either on time or a bit ahead.
In film this is the ideal case, if tou depend on the weather or on certain locations being open, missing your slot can mean that you have to try for a whole week to get it again (or have everybody work on something else and rush them over once it works)
PM guru Eliyahu Goldratt advocated for a 50% likelihood of completion with no buffers for individual tasks, but one shared global project buffer.
I don’t think there’s a single right answer for that percentage, but the key is that it should be determined by the person or group defining the global buffer and should be done with consideration for the distribution of possible durations the project tasks might take.
The expectation when removing per task buffers is that some estimation errors for individual tasks will be high and others low so ultimately to an extent they'll cancel each other out.
In Goldratt's system, the risk comes from the longest (in terms of duration) chain of dependent tasks. Delays early in the chain can only be canceled out by speed ups in later dependent tasks, that's the primary motivation for that global buffer.
The technique was adapted from factory production line optimization. The case can be made that it can work well for projects doing repeatable and thoroughly understood things like constructing buildings. There are reasons it's not a slam dunk for software, but IMO there's still a lot to learn from his work.
Sure, you can do this for a couple weeks. Do this as the normal way of working and you'll end up alone. Burnout is a thing despite we agree or not on the reasons.
> But people being eager to please, and mostly unwillingness to be the one team blocking the entire project - meant that folks worked hard to meet some of these targets. It was extremely hard. It was a bit stressful. It felt crazy at times. But it got done in half the time I would have initially expected such a complex project to take.
Some others have suggested that this might not be sustainable or lead to a sense of personal fulfillment and satisfaction to everyone. Even moreso, that might just accelerate burnout for some, which probably needs to be taken into account.
I remember single handedly shipping around 70 versions of the homepage for Apturi Covid (https://apturicovid.lv/#en), the Latvian contact tracing app, back when we thought that contact tracing would be a viable way to limit the spread of COVID enough for it to die out. I did work a lot, it was a fast paced environment where around 100 professionals in the industry were allowed to collaborate to solve a problem to the best of our abilities and it indeed did result in a positive outcome at the end, the infrastructure, mobile apps and website all being developed in record time, working successfully up until this day and being handed off to the corresponding ministry with no problems.
Actually, i'm pretty sure that if the software were better (not even excellent, just good), a single server rack could probably maintain the entire system (failover aside) and serve the requests for the entire country, which has just 2 million people in it. Yet, it seems that they lacked the "secret sauce" that made our own project successful instead.
Of course, as someone who's single handedly leading an enterprise transformation and doing everything from modernizing enterprise apps in a project, to improving their security, migrating over to new tech, introducing containers, service meshes, APM, additional observability etc., i don't think that time pressure is always all that you're looking for.
After all, you want those that perform highly to be able to do so sustainably.
This article implies, but doesn't come right out and say, something that I strongly suspect: that producing an accurate (or even close-to accurate) software project estimate is a time-consuming, unpredictable task. The question nobody seems to be examining is whether or not the cost of doing a large, expensive up-front analysis that might take an arbitrary amount of time is less than the cost of just doing it concurrently with the software development itself.
I wish I could find the reference, one study showed that additional time spent estimating does not improve estimate accuracy. Only historical data regarding similar tasks were where estimates could be made accurately.
Example: How long will it take you to lean advanced physics? Even if I gave you a week, your estimate is likely worthless (maybe precise, but not accurate). To me this makes sense because you cannot know the unknown unknowns until you hit them (and throw in some of the journeyman fallacy)
Meanwhile, how long will it take to brush your teeth is easy to estimate. How long will it take to brush your teeth with a new electric toothbrush is also reasonable to estimate.
The book Rapid Development is somewhat evidence-based, has a chapter on estimation and concludes the same thing. At every stage of a project, there's just some amount of inherent uncertainty and spending more effort on estimation does not remove this uncertainty -- only getting further in the implementation does.
A lot of these articles assume the work being estimated will remain relevant during the estimated timeframe. My last (very large, not FAANG) employer started every project with a hard deadline, estimates were only used for budgeting not time, and then every project changed on a daily basis until it was obvious it would never ship by the deadline which was changed at the last minute. Every single project worked like this (note these projects were for us not external clients). I know of no theory of estimation that can account for continuous change unknown at the start.
I've worked on reasonably large >$100M defense programs for the last 25 years. Nearly all of them overran both time and budget constraints. They have mostly been firm-fixed price, except for the last 5ish years, that being incentivized agile. I have seen estimation be accurate when the following criteria are met :
1) Experienced personnel are estimating the work (experienced technically and in the product being developed);
2) The work being estimated is of similar technology to existing product;
3) The time period being estimated is less that 6 months
If any of these are violated, e.g. new hires are given the estimation task, a years worth of work is being estimated, new technology is being estimated etc, i would not trust the estimate, and apply big 'ol bucket of risk money.
I actually have seen this legitimately work as well, as in being on a program where we pretty consistently hit every deadline with every planned feature at or under the promised price, for years on end.
But then take the same company, even many of the same people, and put them on a new project, and the estimates go to crap.
It really takes a lot of domain-specific experience, and I mean "domain" pretty narrowly, like knowing the code base, knowing the developers, knowing the customer, knowing the external surprises and constraints you're likely to come across because you've seen them so many times before. I've never seen it work for greenfield, even in an organization with the discipline and know how to do it correctly for their older applications they've been working on for years or decades.
In other words, "estimates" are actually just political and budgetary tools. They have no relation to real-world work. One side agrees to call them "estimates" (the product side) and the other side (the business) agrees to let deadlines inevitably slip.
Oh, people are examining that question alright. It's just complicated and therefore hard to come up with a definitive answer.
If I had to summarise what I have read on the topic, it would be that either way works, but the up-front analysis is orders of magnitude more expensive. Some sectors require this: defense, nuclear, medical, and so on. In most areas, you don't need that and can't afford it in a competitive market.
But to hint at the complexity of the question: Not only is every project different, there are also sneaky feedback loops in there.
By the time you have completed the large up-front analysis the world is likely to have moved underneath you, invalidating some of the assumptions that went into the analysis. You can shape your analysis to account for this, for sure. But at that point does it still count as one up-front analysis or several? Is it truly up-front if it leaves options and decision points open for later?
And it's a continuum: the more options and deferred decisions in the analysis, the more it starts to look like it's clearly done in parallel with the implementation. Where do we draw the line?
I think you, and the agile software industry as large, are completely mistaken.
There is absolutely no problem with intensive up-front analysis. In fact, this is what at least 80% of the effort should go into. But we have pretty much 0% staffing for that role. It's no wonder something doesn't work when no one's there to do it. Compare that to M&S in civil engineering.
Regarding the alleged downsides: Any wrong implementation will incur massive cost down the road (but that cost usually is not accounted for in a SaaS world), so you actually cannot afford to not do it. Assumptions can change, yes, but at least you make assumptions. In agile development, people simply ignore any assumptions and end up with a completely broken product that eats 80% or more of development time with maintenance. And of course, planning and analysis can involve prototypes and iterations.
I came to the conclusion that agile development just shifts the blame for bad planning from management to engineering. And I also think that the correct framework to planning and analysis is domain specific. The more constraints your domain enforces on your software, the better your analysis and estimation will be. Hence greenfield projects have the most problems.
You have me hooked! Don't you think starting (some) development in parallel with the planning is a way to reveal some of the faulty assumptions as such early on? Isn't that preferable to discover that later?
While this is likely true, the problem is W2 labor tends to be compensated on a more or less fixed price per unit of time basis, and to cover that cost, you need to bill clients roughly in proportion to total labor time spent, and most clients aren't going to purchase something for an unknown price to be named later. So you need to estimate to give them a price.
From the perspective of the seller, these estimates don't even need to be "accurate" as long as you're making many of them and the errors are symmetrically distributed. There's even math theory behind this called Fermi estimation. The problem is, from the client perspective, they can't average out the errors over many estimates if they're only buying one thing, and from the seller perspective, I don't think our errors are symmetrically distributed. Instead, we consistently underestimate how long something will take.
It's not even unique to software. There's a huge housing boom going on where I live, with condo developments all over the place, and not a single one is actually ready to open by the season their sign out front claims they'll be open. Defense acquisition. Highway construction. Everything takes longer than budget forecasts claim.
Part of the problem, especially when it comes construction and defense, is awarding contracts to the lowest bidder with effectively no punishment for exceeding the initial estimate. This pretty much guarantees underestimation, both for statistical and behavioural reasons.
I somehow don't believe the "lowest bidder" thing, otherwise everyone would just be putting out contracts for <= $1. However, IIRC from working with people in the government contracting business, the "punishment" is that you don't very easily get more money if you go over budget. If your contract is $100, you get $100 and if you need another $100 you will spend $400 on lawyers and renegotiation.
As far as I understand, the actual "punishment" is government agencies keep track of how badly particular contractors underbid and will simply add that amount to their bids when considering, so they're going for "lowest bid," but the bid they're considering isn't necessarily the bid the contractor puts forward. So theoretically, that provides an incentive to be more accurate, but it only works if there is sufficient competition in the first place and at least some of the competitors are even capable of being accurate.
I believe when awarding construction contracts, some of the deciders look at past projects, which could discount underbidding. Often, other engineers are deciding on the contracts, so they also have a general idea of how much it should cost.
The problem is that once someone gives a date, then they are judged based on that date. In some cases, the software stops making financial sense after some multiplier of this initial date.
To avoid estimation you need to avoid dates and avoid projects that have high timeline risks. This means you would need to judge on speed to completion, or better customer satisfaction for project execution.
If think about estimate as learning activity in the sense of Theory Building, then you won't really care about the estimate by itself (which is a nice by-product) but as a confirm that the task is clear and actionable. In that the real value I think.
Isn't this basically scrum? Instead of doing an estimate at the start, you determine the throughput of the team and then give an estimate based on that measurement. That's my understanding of it anyway, could be wrong on that.
Treating every project as if it's in emergency mode is a great way to burnout the team and get shoddy work results.
Another idiotic practice is multitasking since context switching introduces tons of overhead.
And tying it all together, the importance of a project determines its resources. A truly critical task needs 100% focus. If a manager isn't willing to assign a full-time employee to a task, then that project isn't critical.
> The Yerkes–Dodson law refers to an inverted U-shaped relationship between performance and arousal, where performance increases with arousal, but only up to a certain point.
The quest to discover and apply "laws" like this courts disaster or disruption because people are neurodiverse. ADHD people respond to deadlines in a completely different way to non ADHD - sometimes inversely, sometimes obversely, and so require different management. Same but different with autistic spectrum people, introverts, extroverts, bipolar, insomnia, sleep apneates, diabetics and long covids.
It may be tempting to dismiss neurodiversity as a fringe consideration and just assume most people are "normal", but their circumstances, both in the workplace and beyond it, may complicate Yerkes-Dodson as much as neurodiversity whilst evading detection by managers and systems.
Well written and thorough article, but I can't help notice if this isn't just reverse engineering a standard MBA curriculum.
> Time pressure is also reported to be the most frequent external cause of unhappiness among developers.
> The inverted U-shaped relationship is one typical example of this, which means that time pressure increases efficiency up to a certain point, but after that increases in time pressure cause a decrease in efficiency
A good manager knows how to sustain just the right amount of pressure.
> [In this article, time pressure refers to both budget pressure, e.g., eight hours (budget) to do a task, and schedule pressure, e.g., a task that must be done by tomorrow.]
Aren't these the same thing? the latter being somewhere around 24hours give or take
I may want something to be done by the end of next week and at the same time I would like somebody to spend less than 4 hours on the task. Spending entire two weeks of effort would not be acceptable in this case even if the task was delivered on time.
An example would be a task that is not on the critical path of the project but still needs to be done. There is a deadline by which it must be delivered or it becomes part of critical path and starts delaying entire project.
Assuming the task is performed by one person using the fraction of the time available before the deadline, I would like to be able to use the rest of that time (resource) as either a buffer in the project or for completion of another task. Having the person deliver the task before deadline but after two weeks of continuous work where I assume only 4 hours will be necessary means that the project was deprived of almost two weeks of buffer or there are now some other uncompleted tasks.
When we are talking about project management, there is an important, clear distinction between time and cost.
>>> An example would be a task that is not on the critical path of the project but still needs to be done. There is a deadline by which it must be delivered or it becomes part of critical path and starts delaying entire project.
I know it is picky but, if a task "needs to be done" then it is on the critical path. Just because "build the bridge" is not needed yet, it is on the critical path even before you arrive at the waters edge.
I am of the opinion that pretty much every project management function can be replaced in software.
> I know it is picky but, if a task "needs to be done" then it is on the critical path.
You are wrong.
Critical path is the longest path from start to end of the project. It dictates the length of the project. The idea is that if any of these tasks takes longer, entire project takes longer.
Has nothing to do with whether the task is important in itself. But the task on critical path is important from the point of view that it has power to affect entire project.
You can still have tasks that need to be done that are not on critical path. This usually means the task can be done in parallel of some other critical task and you have more time available to complete it than the time slot where you can work on it.
Imagine you are manager with only two employees. One employee can only write code, the other can only write documentation.
Your project requires delivering to the client completed application with documentation.
It takes 1 month to complete development and it takes 1 week to complete documentation. Moreover both employees can start immediately because they both know what needs to be done.
Which is critical path?
If the documentation task slips by one day, the project will not take more time. On the other hand if development slips it will.
From that point of view, development is on a critical path.
It does not matter which task is more important. If you had bright coder that took one week for development and slow writer that took a month to prepare fantastic documentation, the situation would revers and now it would be documentation that is on the critical path and where you will focus as a project manager to deliver it on time.
Maybe this will be hugely impopular, but in addition to the three causes mentioned, isn't it possible that one cause actually comes from developers simply not performing?
If comparing to sports, in a team, is it always the coach's fault? Or is it possible that one player is not performing as expected? Is it then the coach's issue that he/she didn't expect that?
At the beginning of my current job (I joined as CTO) I had to inherit a lot of misunderstandings that the management team had.
They had hired people who knew nothing about building software (before me joining), most likely those people have never really built and shipped anything. Everyone on the management was under the impression that software is easy and everything needs to be delivered on time and if it's delayed we need to throw more money at the problem and that would solve the problem. They would continuously ask for "timelines" and never understood the word "estimate". They knew the definition of the word but could never accept the reality of the definition.
I was tasked with building a brand new core banking engine and a kyc engine. I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc... So they needed to first be trained.
To cut a long story short I was the only one on the team to be able to write productive code to build such a complex system. I hired someone who could write code to help train the existing team. However given the complexity of the problem and the tight timelines I had to solve. I basically did the design and implemented about 70% of the code myself while my other teammates were being trained. This also included building a KYC engine along the way. I remembered suffering immensely building the engine and hiring / building the team. I would focus on working with the team during the day and coded at night, since that was the only time I could get un-interrupted hours to code.
I worked til 2AM almost every night for 7 days a week for over a year (6 months to get it to launch and then refinements / continuous improvements after). To complete the engine and get it to serve hundreds of thousands of transactions every month. I was never paid for overtime. Today the company stands strong with handsome profits.
Trust me. I can tell you, the problem is not the developers / process / agile / kanban / etc..., the problem is management. It's always management. I was able to get management to understand the true scope of the task by stopping working overtime and standing my ground (when the company had recovered and was able to produce a stable income to support itself).
The overtime I did hid away all the 'complexities' and the 'debt', and prevented the company from learning. I basically ended up paying for the company's mismanagement / toxic culture with my time. Fortunately a lot of toxic people left the company, a growing company will generally push out the non-performers organically. It took a lot of effort on my part personally to resolve issues plaguing the company, establish an engineering culture, build a strong tech team that can withstand pressure and deliver continuously and can build on top of the framework I provided.
The lesson has always been. It's never the software team (at least never the team I manage) whom are not productive or doing their best. It has always been management / company culture / never truly understanding the scope / requirement enough to understand how huge of an undertaking a given project is. I can tell you without a doubt this article pretty much hit the nail on the head. I'm living proof and have the battle scars to prove it.
Now I tell management about time estimates as it is. "No fixed timeline, the team estimate, the team builds, it's done when it's done, live with it or fire me."
I've fortunately afford myself the position to be able to deliver the truth serum to management and they have no choice but to accept it. It didn't come cheap, I'm still scarred.
I agree with this wholeheartedly, as someone currently going through a similar experience.
Management is an incredibly complex job, especially in software engineering, and the fact that we "promote" senior developers to it as if being a good developer was the only requirement to being a good manager is part of the issue in my opinion.
I'm sorry you went through this, and I'm glad you were able to extract some good out of it.
> and if it's delayed we need to throw more money at the problem and that would solve the problem.
> I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc
Where was all this money going that they were throwing at these problems if they are hiring fairly low level staff like this?
Great that you managed to do it, I would have just walked away.
I have long learned such personal efforts are worthless, specially when the next firing round doesn't care about them, just a thanks for the fish and see you around pat in the back.
TL;DR, literally, I didn't bother to read the whole thing. Time pressure will never go away. It only takes common sense to realize that those who want something, i.e. are paying for it, want it as soon as possible. The difference from making physical things is the perception that software is soft: it seems to be infinitely malleable and all it takes is hand waving magic or sheer willpower to manifest it. This is of course the lie that those building software understand, and those that do not, will not.
