Every time I see those I also see the lesson - count your maintenance costs. It is a nice artificial water channel, yes, but will the city have the money to run it, clean it, supply water, etc.?

Of course I know that the original (real estate) developers did the cost analysis, but when you see those abandoned places - very much objectively you can conclude that they made an error. A miscalculation, or an error in judgement.

--

Back to software I think scope creep causes many problems: the team loses focus, can be demotivated by delivering the features no one needs, etc. - all real and serious problems. But ultimately it is the ever growing maintenance cost that has a real ability to annihilate all team capacity.

Everything we build, however high-quality it is, needs to be maintained and all projects should include this into their "run" phase budget. And growing maintenance costs only aggravate other scope creep issues.

--

And that's the tragedy of being the engineer/engineering manager/CTO even. Exactly like the post says, you don't get "promoted" for stuff you reject to do. I had countless occasions of successfully convincing product teams and boards to abandon or shrink the project, and although I am convinced it did good for the companies in the end - the engineering department ends up being a buzzkill :shrug: . I cope with it, but it never really settled with me. If anyone has the answer to how to approach this in a healthy way I am very much interested in your experience.

- llms let us build exactly what we want fairly quickly nowadays, or at least a prototype and

- being able to build these features (or separate products) quickly is exactly the trap

> It’s the same test I keep applying when picking the right problems to solve — does it make the boat go faster?

Who knows this though? It's rarely engineers. Product often has a good sense within their lane. Leadership usually (at good companies) is mostly aligned, with some nuance depending on who's speaking.

It's a good sentiment but rarely a single person's decision.

As I said, I see these pop up and I'm usually annoyed because what new take could someone bring at this point, but I read them every single time :p

The next best thing is to rapidly build the crappiest thing that kind of works. Being a little bit bad on purpose usually helps. Getting trapped in clean code and test coverage ideological hell is precisely what we want to avoid.

I've found that the more aggressive you make your time constraint, the less likely you will wind up committing to some kind of engineering decision that ruins the whole pie.

If the 90 minute rapid prototype doesn't make sense, you didn't waste that much time. It's a lot easier to prove things to stakeholders this way too.

I've turned multi-month product roadmap expansion packs into single day tasks by building the right things at the right times in order to discover what not to build.

Before they add any new UI element, they first look for something they can remove.

Self-promotional link: https://killthehippo.com/

As an engineering leader you’ve got to advocate for it against product/design all the time.

When you are flooded by requests, predicting the right priorities and managing the Gantt is crucial.

Customer satisfaction is your priority as consultant, but wisdom is even more valuable, if you can apply it.