Hacker News Reader

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.

Get out of my head.

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).

Until they get burned, then they work for noone else afterwards.

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.

This sounds like a system where those who don’t buffer get stuck working long hours. Those who add a buffer don’t get stuck on long hours.

This is how it is in finance.

Your life is your work, but the ability to own 5 houses is a nice balm.

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.

Wouldn't that mean in a ideal world half the estimates will be under? That buffer would have to be half the size of the total project or so.

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.

In contrast, our national e-Health system has been in development for years, has cost around 14.5 million euros so far and still doesn't work: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/par-e...

It's actually so bad that they're considering creating a new one to replace it, something that could have probably been avoided with enough care: https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/...

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.