|
|
|
|
|
by royaltheartist
1078 days ago
|
|
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 |
|