Personally, I've found that lack of code maintainability is multi-faceted, though I think any one of these could be causes all by themselves:
- A focus on delivery over correctness. Managers too focused on the immediate, with no foresight relating to Technical Debt.
- A focus on cheap delivery over a well-thought-out design. This is related to the previous item. What's the cheapest way to get this out the door now?
- A focus on minimal code to delivery over preparedness for last-minute changes you know will come up (even if you don't know the specifics). Robust, flexible code is not a priority.
- An unwillingness of the developers to overcome the above.
- A lack of repercussions in developing bad code. This probably is a partial cause of the previous item.
About three years ago, I switched into a focus on code-in-the-field support over next-big-thing development. Which means I've had a couple of full releases "thrown over the wall" at me any my team to maintain and perform problem-resolution on with paying customers, while they go on with less knowledge than ever about what customers are actually doing with our code. I don't have time to educate them on every issue that comes up, and, besides, experience is the best teacher, while I would be a distant second. (Well, if you only have two options, I'd be the distant second. Add more options, and I fall in the rankings fast.) When I was doing the next-big-thing development, I would always, even when management wanted something else, do a Scottie-style estimate: double and add one / round up, regardless of units. Something that a coworker would size at 3 days, I would size at two weeks (3x2+1 = 7 working days, round up to two weeks). My co-worker would get an unmaintainable mess at the end of four to five days, yet I'd have something maintainable and flexible in three to six days. It was a focus of mine because I knew that the fewer problems that customers had, the less they'd call for support. The less they call for support, the less that the customer support people would bug me. The less they bug me, the more work I could get done. The more work I get done, the better my year-end review, and thus the better my raise/bonus. It was all about the cash. I don't quite get why my coworkers missed this.
Meanwhile, now that we've split the responsibilities, there is no negative repercussions, no negative feedback to the original developers. They code in a vacuum. And quality has gone to $#!+.
But that's just my take on it. I'm so looking forward to moving to another team that does both next-big-thing development AND development-support of in-the-field code, hopefully by the end of the month if all goes well.
| [reply] |
I would add the following to your list of causes (of bad/unmaintainable code):
All too frequently, prototype/POC code (never destined to be maintainable in the long-term) is delivered as a fait accomplit - instead of code engineered on the back of the results of the prototype/POC process.
All in all, methinx this (c/w your observations) can all be summarised using the age old maxim/adage:
We can always afford to do it [develop the code] wrong many times, but seemingly we can't afford to do it right first time
A user level that continues to overstate my experience :-))
| [reply]
[d/l] |