4 ms·

To be devils advocate, I've seen many "anit-superheros" of maintainability do months of work and not end up with an objectively "better" body of code. Often it'

by tensor 6y ago

To be devils advocate, I've seen many "anit-superheros" of maintainability do months of work and not end up with an objectively "better" body of code. Often it's just different, and sometimes slower hard harder to extend due to premature abstraction. There isn't an easy answer here, but incentivizing speed of iteration (aka shipping) has several benefits, both to getting value to customers as well as to architecture and maintainability of the code.

hobs 6y ago
I think that most of those people are not familiar enough with the system that they are complaining about to understand why its so complex. I have been involved in paying off many kinds of tech debt, and I see a lot of people scream maintainability and then realize the problem that the horrible thing solves is itself a horrible problem. If you can fix it, fix it, if you think its going to take months to years of work to fix it to be maintainable the truth is likely you never will. Any product that is static long enough for you to do this is probably not making enough money to justify the cost of doing that kind of refactor except as a hobby project (or was really well designed in the first place, or is a literal hellscape you should let die.)
PaulStatezny 6y ago
I totally agree with that, but I'm not sure I agree it's playing devils advocate. By which I mean, I don't think we're disagreeing here. They're both real things that happen: 1. People rushing out crap code and not taking responsibility for cleaning their mess. 2. People trying to clean up code, but doing a poor job for various reasons. (Incompetence, lacking sufficient domain-knowledge at the start, bogged down by organizational problems, etc.) The problem in each case is people either lacking the capability or desire to do excellent work. "Ship fast or write decent quality code" is a false dichotomy.

by tensor 6y ago

hobs 6y ago

I think that most of those people are not familiar enough with the system that they are complaining about to understand why its so complex. I have been involved in paying off many kinds of tech debt, and I see a lot of people scream maintainability and then realize the problem that the horrible thing solves is itself a horrible problem. If you can fix it, fix it, if you think its going to take months to years of work to fix it to be maintainable the truth is likely you never will. Any product that is static long enough for you to do this is probably not making enough money to justify the cost of doing that kind of refactor except as a hobby project (or was really well designed in the first place, or is a literal hellscape you should let die.)

PaulStatezny 6y ago

I totally agree with that, but I'm not sure I agree it's playing devils advocate. By which I mean, I don't think we're disagreeing here. They're both real things that happen: 1. People rushing out crap code and not taking responsibility for cleaning their mess. 2. People trying to clean up code, but doing a poor job for various reasons. (Incompetence, lacking sufficient domain-knowledge at the start, bogged down by organizational problems, etc.) The problem in each case is people either lacking the capability or desire to do excellent work. "Ship fast or write decent quality code" is a false dichotomy.