I’m a little less zealous in my dislike of it. It’s not that the process itself is “bad”, the ideals behind it make sense. In practice (my own experience) it easily degrades into what I call “fake work”— you feel like you’re doing lots of productive measurement and estimation by drawing nice little boxes around projects, but projects rarely ever work this way. The one thing I see constantly is moving on to the next project because we checked off all the agile boxes, without giving much care to maintenance. There is always maintenance work, and it’s very easy to turn a blind eye to.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
> Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
When the great CPU architect Stephen Keller was on Lex Fridman's podcast, he made a comment that architectures should be refactored every 5 years and I thought to myself, "Good luck with that in Enterprise" as I looked over at the 10+ year old legacy infrastructure holding back org-level velocity at work
oof every FIVE years is an eternity in software years. Maybe I have been working alone for too long while between jobs, but it just feels so much better to listen to all of your hunches about it being refactor time than to ignore them for the sake of functionality. It's just not possible to act on the hunch later when you have lost that important deep context and hastily added twelve other things too.
Tbf he was specifically thinking of CPU archs but at "Enterprise Scale" might as well be talking 10 years. Personally, from your comment, I'm learning to just stop giving a fuck and apply the (obvious, cause, you know, you've been looking at it for 5 years at least) re-factor regardless
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.