Comment by jiggawatts | Hacker News Reader

Comment by jiggawatts | Hacker News Reader

This is actually a really good summary of how projects should be estimated. A lot of people I know just focus on the core task or the minimum viable product, ignoring everything around it.

I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. In reality, the post-go-live support can take a surprising amount of time, but is rarely accounted for.

One particular customer, a telco, had PMs that started in the telephony space and were especially stuck in this mindset. Imagine digging a trench and laying down some fibre for a customer. The second the hole is filled and the fibre is lit up, the project is done. There is zero ongoing maintenance! Fibre doesn't need monthly patching, or regular replacement. It lasts decades. Sure, it might be cut by a backhoe, but that's break-fix, not project work.

Now picture the same mentality applied to general IT projects. Build it, mark the project as closed, and walk away. Never patch anything. Never upgrade. Never consolidate. Just leave things precisely as-built forever or until it breaks...

... or gets hacked and makes national headlines.

> I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away.

This mentality and Agile mixed together creates monster technical debts. A team is rushed to create an MVP. Since it’s an MVP, things are skipped, rushed and riddled with edge cases. This is fine if the team can now use the customer feedback and deeper understanding of the domain to iterate and polish the product. Write some documentation, refactor rough edges etc.

But of course, this often doesn’t happen and the team begins sprinting to deliver on yet another “top priority”. After a while, management starts to wonder why doing anything takes forever and devs are leaving.

Scrum is so anti-agile it's not even funny. Just TRY to convince a scrum lord that maybe we shouldn't put process before people. It's a treat.

As a PM I feel seen. So many past experiences in companies with poor product culture where this happens. Companies like to say they’re hot on agile and have a strong product culture involving mvp, test, learn, iterate frameworks but in reality so many are just; mvp, test, learn, release, move on to the next different mvp

Leadership often say they want agile processes and iteration but at the end of the day they just want releases of new features

> but at the end of the day they just want releases of new features

I do not understand how this reality could surprise any professional developer.

Code quality, clean architecture, elegant algorithms, technical documentation, unit tests... they do not sell. Whatever my process is, if it is not aimed to a constant output of new features and bugfixes, then my process is not good, and I am an idiot to insist on respecting it.

> In reality, the post-go-live support can take a surprising amount of time, but is rarely accounted for.

Really the most frustrating part of PM. I have never had a PM that understood "we could implement features faster if we took a little time to go back and tighten up the code". Instead it's just a constant stream of one feature after the next with whatever got written down the first time by a fresh college grad being the golden solution.

It's particularly frustrating because PM tend to measure success by the number of features produced. That alone incentivizes a fair number of devs to just pump out shit without thinking about what they are producing.

It's like running a marathon and you keep falling on your face because your shoes are untied, but you "don't have time" to stop and tie them, so instead you just keep tripping over and over and over while your competition recedes into the distance.

Bonk.

In the limit, you reach the level of that joke I remember hearing as a kid (and I think it dates to post-WWII rebuilding / soviet era). One possible retelling:

An outside inspection comes to a busy construction site. As they watch the workers running with wheelbarrows, back and forth between material storage and active construction, they notice that all the wheelbarrows are empty. They flag a foreman, and ask him, "why are all these workers pushing empty wheelbarrows around?", to which the foreman replies, "we're so swamped with work, there's no time to load them!".

Also heared the story in my childhood. The reason they are keep doing that is that the loader guy is missing and they are not going to be paid unless a reward from some work.

From my experience, it's the business pressuring the PM into situations like this. If PMs want to keep their jobs, they're often just as helpless as the devs having to execute the work.

Sounds like Xtreme Go Horse Methodology. It is the fastest and therefore best. https://github.com/Brunomachadob/xgh

As a PM of a large ML team, articles like this and comments like yours keep reminding me of why I should push back when I get asked for estimates and if I really need to give one, then at least I can empathise with my team and ensure that either estimate is large and roomy

Reply on news.ycombinator.com