5 ms·

No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. I

No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. If development is done properly, "maintenance" isn't some massive chore. It's pay-as-you-go and takes the form of proper testing, early design review and refactoring, and a shared sense of responsibility for the upkeep of the code (none of this "give maintenance work to the juniors" attitude). When a company decides to put its junior people on full-time maintenance to have them pay their dues, it's setting itself up for failure. Unskilled maintenance makes the code worse. Unmotivated maintenance makes the code worse. Finally, even in the best-case scenario where the junior programmer is motivated and skilled, he still doesn't have the clout to do maintenance properly, which often pisses off people who depend on ill-thought-out features. Ideally, people who care about an asset (i.e. who use it) should be the ones to maintain it. Ideally as well, the maintenance overhead should be small enough that the "stakeholder" can perform this maintenance pay-as-you-go at the same time as doing other things. Maintenance is really only done well (and if it's done well, it improves rather than "maintaining" the code) when done by people who have reasons to care about the system they're maintaining. Once a project's maintenance overhead is measured in X full-time developers where X >= 0.5, it's time to stop pissing away time and money and motivation and kill -9 that sucker. The warning range is 0.25 to 0.5 full-time developers. If the maintenance burden is in this range, it's time to get a competent person into fixit mode (not "maintenance", but active improvement and refactoring) immediately. Here's my somewhat long post on the topic: http://michaelochurch.wordpress.com/2011/09/23/taxation-without-representation-why-code-maintenance-fails-and-how-to-fix-it/ http://michaelochurch.wordpress.com/2011/09/23/taxation-with...

bobbles 14y ago
My first real programming job was 100% maintenance. It was horrible. Luckily I was able to get out after 6 months, but still wonder about the other guys I was working with there.. hopefully they got out.
- gcb 14y ago
  He should be glad it's not 90% maintenance and 10% meetings
  - gouranga 14y ago
    Or in my case 90% meetings and 10% maintenance!
  - philbarr 14y ago
    He should be glad it's not 90% meetings and 10% maintenance you mean, which is what's waiting for him if he stays in the business long enough.
nandemo 14y ago
> No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. In my experience and from what I've gathered from friends and coworkers over the years, ratios like that are actually quite normal. And it doesn't have to do with entry-level vs. senior. I suppose a lot of HNers are working at tech startups or otherwise companies that build software-based products. But there's a lot of custom software out there (I'd say the large majority of running software as well as the large majority of software being written is custom, though I have no data to back that up). So lots of devs are either working in-house for non-software large companies, or working for companies that build custom software for such companies, and that usually entails a lot of maintenance work.
- mgse 14y ago
  I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year. I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing. And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago. As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.
- ryanmolden 14y ago
  I think it has more to do with primarily only having experience with code you wrote yourself or a small codebase written by yourself and others. I have a tongue in cheek saying of "If you haven't maintained code written by others then you probably write code like an asshole". You learn a lot about what never to do by working with very large (and/or very old) codebases that you yourself didn't design. Also, to be fair to the people that did design them, even your greatest most beautiful design will look terrible to some people, and likely to posterity.
brazzy 14y ago
Are we perhaps using different definitions of "maintenance" here? If by maintenance you mean "dealing with bugs", then yes, 90% is too much. But if it includes adding features, then 90% is perfectly normal if not a bit low.

bobbles 14y ago

My first real programming job was 100% maintenance. It was horrible. Luckily I was able to get out after 6 months, but still wonder about the other guys I was working with there.. hopefully they got out.

gcb 14y ago
He should be glad it's not 90% maintenance and 10% meetings
- gouranga 14y ago
  Or in my case 90% meetings and 10% maintenance!
- philbarr 14y ago
  He should be glad it's not 90% meetings and 10% maintenance you mean, which is what's waiting for him if he stays in the business long enough.

nandemo 14y ago

> No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. In my experience and from what I've gathered from friends and coworkers over the years, ratios like that are actually quite normal. And it doesn't have to do with entry-level vs. senior. I suppose a lot of HNers are working at tech startups or otherwise companies that build software-based products. But there's a lot of custom software out there (I'd say the large majority of running software as well as the large majority of software being written is custom, though I have no data to back that up). So lots of devs are either working in-house for non-software large companies, or working for companies that build custom software for such companies, and that usually entails a lot of maintenance work.

mgse 14y ago
I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year. I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing. And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago. As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.
ryanmolden 14y ago
I think it has more to do with primarily only having experience with code you wrote yourself or a small codebase written by yourself and others. I have a tongue in cheek saying of "If you haven't maintained code written by others then you probably write code like an asshole". You learn a lot about what never to do by working with very large (and/or very old) codebases that you yourself didn't design. Also, to be fair to the people that did design them, even your greatest most beautiful design will look terrible to some people, and likely to posterity.

brazzy 14y ago

Are we perhaps using different definitions of "maintenance" here? If by maintenance you mean "dealing with bugs", then yes, 90% is too much. But if it includes adding features, then 90% is perfectly normal if not a bit low.