Comment by royaltheartist | Hacker News Reader

Comment by royaltheartist | Hacker News Reader

Parent Full thread

Personally it feels like modern management and organizational practices have prioritized feature velocity over a lot of other concerns. Business likes this because they can come in, request X number of features and then everyone works like hell to get those features in

Then, seeing the speed with which those first X features got implemented, they now request Y features and the cycle repeats.

But constantly measuring feature/release velocity means that things that do not directly benefit new features/releases get de-emphasized, such as encouraging developers to not just implement a feature, but go back to their code and try to disentangle the code they just wrote from any other code they may have stepped on. And it's even harder to get the business to agree to not push out features but instead give time to just go back, look and what's there, and figure out how to make it possible to add the next Y amount of features

There's something intoxicating about being able to have a bunch of teams pushing out new updates, but these high velocities can make it near impossible to revisit something. Hell, I've gone back to code bases on projects I haven't touched in only a few months to suddenly find everything has become riddled with spaghetti code and weird hacks to bypass systems. It works, but each release starts developing longer and longer bug fixing time

In my experience one way this manifests is how every new project you'll get PM and management rushing you to use some dead simple user authentication so you do then 6-8 months later they're asking you to add RBAC to all the features you've had nothing like that planned for. Like it's the most obvious eventuality with any of these apps sold B2B and it's always put off and fucks up any architectures and forces various "pivots" because management couldn't be bothered to listen and prioritize foundational stuff.

Management practices are bad because managers/directors/VPs are not the first to be fired.

In a scenario where the management would be the first to be fired for non-delivery of features, management would go to extreme lengths to improve developer environments, tech debt, and in keeping people happy and for longer duration.

Management incentives need to be changed.

100% this. Velocity above all else, in conjunction with the bad practices around treating product as the source of truth pretty much always, and pushing back on technically infeasible (for the time frame, usually) is a no go.

I know as engineers we have some salary privilege, but few groups get squeezed as hard by both sides of the business layers as engineers do, in my experience.

> Personally it feels like modern management and organizational practices have prioritized feature velocity over a lot of other concerns.

I agree. In the defense of business, our industry typically does a horrible job explaining concerns other than features. This isn't going to change things across the board, but I think a meaningful percentage of businesses will make better decisions with more mature presentations.

Reply on news.ycombinator.com