|
|
|
|
|
|
by thirdtruck
4142 days ago
|
|
|
And a lot of these seemingly trivial, familiar tasks require far different time than estimated (both less or more) precisely because no one went back and rebuilt things, thereby leaving an inconsistent, incoherent spaghetti mess behind them. Editing code is more akin to rewriting essays than re-engineering a machine in that way: It's going to take a lot more effort to make a 3rd grader's essay print-worthy than one of Hemingway's. |
|
|
Generally my experience has been that the inconsistent, incoherent mess develops when people tasked with doing trivial changes try to "fix technical debt" in the process, leaving you partly on the way to a "better" model, at least until the next guy comes along. And then the next guy. Until you have a layer cake of different approaches and technologies and philosophies, degrading to a worse and worse state.
Look, I've been doing this for 20 years. Almost everything I work on tends to be novel code. I'm terrible at estimating, and now refuse to do it at all. But there is a lot of self-serving, well, nonsense that we ply in this field, justifying our failures (and the reality that most developers don't want to learn other people's code, so they just short circuit the whole thing and pretend it's higher ground), and the whole "technical debt" thing is one of the most egregious. Most developers, when asked to do something to existing code, will throw their hands up and declare it the worst code they've ever worked with, and they can't possibly make some trivial change without completely rewriting all of it, etc (usually somehow pulling in whatever the pet technology of the month is...sorry, I can't change the web form without turning it into a single-page app built on io.js and React and...). We all tell each other this on boards that we dominate, not realizing how completely ridiculous and transparent it really is. It's always more fun to build something novel than to just modify things that exist.
Which is why I really think maintenance programmers are a unique and valuable breed for businesses to have. I personally have a weakness that I always need to rebuild things. I'm terrible as a maintenance programmer, so I simply don't do it. But there are some people who are perfectly happy adapting to whatever they are working on, learning its idioms and unique traits, and then competently and quickly making necessary changes without drama and theatrics about how dire of a situation they've been put in.
To abuse the analogies that have been plied, it's being asked to drive somewhere, and first re-building the car into an electric car, then a self-driving car, and then deciding that you want it to be a hyperloop, and then talking about relativity, all while the business just wanted to get from A to B.