We Really Don't Know Jack About Maintenance

davecb writes "The ACM has been kind enough to print Paul Stachour's and my 'jack' article about Software Maintenance. Paul first pointed out back in 1984 that we and our managers were being foolish — when we were still running Unix V7 — and if anything it's been getting worse. Turns out maintenance has been a 'solved problem in computer science' since at least then, and we're just beginning to rediscover it."

Comments

"Everyone knows maintenance is boring"

[tomhudson]

FTFA:

Everyone knows maintenance is difficult and boring, and therefore avoids doing it

Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.

It's all in the mindset. It's only boring if you limit yourself to the boring parts.

Re:"Everyone knows maintenance is boring"

[Anonymous Coward]

Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.

What company do you work for where it is even remotely possible to accomplish all that and still meet your deadlines? In my world, you always wish you could totally refactor the code like that, but there's never enough time in the schedule for that. So instead, you "make it work" as best as you can, and that's about it. Maybe, if you're lucky, you can find enough time to do at least a partial re-write of the worst parts of the code, or tidy up an interface or two. But cutting the code size by half? Yeah right. I wish.

Re:"Everyone knows maintenance is boring"

[steelfood]

More likely, the code was written and documented badly in the first place, so it's not a matter of taking it and cutting it down into something more elegant. Instead, it's about trying to decipher exactly what's going on, then trying to figure out how to make it at least superficially better while trying to keep within the same crappy framework. This has to all be done within budget, or the work done will go to waste when the project's scrapped, and there won't be a budget for maintenance again.

Maintenance isn't a rewrite from scratch to do the same thing, as much as we'd like it to be. Production systems have to be kept up. Migration to new code has to be both backwards compatible and produce enough visible results to make it worthwhile. It can't be too big of a change, nor too little. It's hardly any wonder software developers don't get to, and managers don't want to do it.

Re:"Everyone knows maintenance is boring"

[tomhudson]

You don't tell them you're doing that ... you just do it. It's quicker anyway. Start by cleaning up the formatting and moving stuff into headers, some righteous macros to make the code more readable, etc., as a first step in "getting familiar with the code. After all, you don't want to break something while fixing a problem. You'll probably notice some code that looks like it's either "copy-n-paste" or dead. Keep it in mind.

You'll find potential for simplifications as you go along, and you'll also probably find other bugs and stupidities, like parameters that are never used (that happens a lot as code gets modded). Code that doesn't smell right. Signed ints that are unsigned elsewhere. Potential buffer overruns. Unsanitized unput. In-line code that really should be in a separate function call both for clarity and for re-use. Look through the bug list - if the bug (or potential bug) you found is there, great - mark it as fixed. If not, log it, then mark it as fixed. Either way, your fixed bug count goes up - and if you can show that you've fixed bugs before they're found, that's just a bonus.

Now start a bit more higher-level fixing. Nothing too wild, but if you have to add a bit of functionality, use that as an excuse to simplify the code that it touches. You'll probably confirm some of the dead code from the first step. Remove it. You'll probably confirm cases of multiple instances of copy-and-paste - refactor them as well into something a bit more same. Now you've removed a few more bugs, shrunk the file size, and added some functionality.

Now that you've done that, review the code again, and look for more instances of copy-and-paste. Code that was written in a hurry will have LOTS of it, so you'll definitely be able to give it some more w8loss treatments. And since you didn't bitch and moan TOO much about making the mods, and they actually work, they'll probably be happy to let you graze on the bug-fix list. There's always bugs, nobody wants to touch them, and as you clean up the code, you'll see it start to shrink.

A 50% reduction on crappy spaghetti code is reasonable under those circumstances.

At that point, you own the code. You're in the loop for changes that might break it. When you say, "okay, but it's going to take x time" they're more likely to actually listen. Consider it office politics for nerds.

Re:"Everyone knows maintenance is boring"

[bjourne]

That's great, until your huge refactoring introduces a new bug. And it will, you can't expect to refactor a decent sized body of code without breaking something. When it does, it doesn't matter that the code is 100 times more readable and extensible, or that you fixed ten other bugs while doing it, your ears will get hot. Because you broke something which means more work for someone else and that the count of outstanding bugs was just incremented.

This happens in the places where each bug report has to be annotated with about two dozen different abbrevations and numeric codes so that the correct departments and bug examiners will get to look at it. When it takes two hours to file bugs and each bug has to be examined by four persons, you can forget about filing bugs about "potential problems." Bug reports are for the issues customers have complained about and nothing else.

What about the next bug report that comes on? If it can even remotely be associated with the new code you wrote, then it will be. Because yours is the only new code in what is otherwise a totally legacy code base with hundreds of band aids. Expect to take the blame.

And then you have the original author of the body of code you just killed/refactored. He wont be so amused about you rewriting in one week what he spent four months writing. Expect to hear nitpicks and complaints from his side. You won't be able to ask him anything about the code anymore because "you destroyed it."

So yes, while refactoring code makes it better, you wont make many friends while doing it and you are taking a huge personal risk. Especially if you are doing it secretly.

Important forgotten steps

[Lord Grey]

• One Iteration Planning Meeting (minimum four hours in duration)
• One Integration Planning Meeting, to schedule changes with all other changes (minimum three hours in duration)
• Twenty Stand-up Meetings (two per day for ten days) so everyone can tell each other why they're behind on the planned changes
• Two scheduled Backlog Meetings to reschedule the planned changes that won't make it into this iteration
• Six presentations to the Senior Management Team of at least one hour each to communicate our effective Change Management Strategy
• At least three Tag-Up Meetings, called spontaneously, because some people still just don't get it, originally scheduled for 30 minutes each but extended to 60 minutes because exactly one person in the room wanted to argue
• One Retrospective Meeting, which no one wants to attend because they're already behind on the backlog tasks

Re:Important forgotten steps

[NoYob]

You know, if you numbered them, then you can write a book (of course add a lot of fluff and unsubstantiated horseshit) called "The 7 Habits of Highly Ineffective Software Teams", have it published, be a huge hit, milk the fucker with another book called the "8th Habit", workbooks, do lectures at $50,000 a pop, and after a couple years, retire rich!

Dipshit PHBs would be buying them left and right!

That is not maintenance.

[SuperKendall]

Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.

Yes it is.

But that is not maintenance, as practiced by any rational company. That is development or (more specifically) optimization.

Maintenance is about solving a problem code is having, with the absolute smallest number of changes possible. Even new features can fall under this heading when software is in true "maintenance mode" in order to avoid a lot of excess testing.

I actually don't mind it, as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible. But it's not as glamorous as fresh, raw coding.

six sigma

[bunbuntheminilop]

Could a six sigma program help here? A systematic and structured approach to problem solving is needed. Whenever someone fixes a bug that creates a new bug, then it's a waste of everyone time and effort.

Different Kinds of Companies

[digsbo]

Decades ago, companies which developed technology were...technology companies. With real engineers, and highly technically skilled management. Today, companies with business-oriented management and zero technology background own and develop systems. They often do it poorly, with insufficiently empowered engineering teams, and insufficiently skilled engineers.

So today we've got a lot of Java and .Net shops filled with junior-level programmers and no disciplined, experienced systems engineers. Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering?

Re:Different Kinds of Companies

[pwinkeler]

When I worked at Analogic Corporation [www.analogic.com] in the mid-eighties, the then owner/president/ceo Bernie Gordon refused to grant anyone working in software the title "Engineer". We were all "just" programmers. Until we could show him specs and tolerances and statistical failure rates of our designs we were nothing but a bunch of untrustworthy programmers. And you know what? He was right: we still are.

Theory vs practice

[Anonymous Coward]

Doesn't modular programming solve this problem?

That is one of those answers that sound great in theory but in practice suffer from all the same problems from which all the other answers suffer.

Too much upfront cost is a contract-killer, so compromises in designing for scalability must be made.

Furthermore, today you have ideas about how the software will be used, and tomorrow those ideas will be changed, and you will discover that the dividing lines you have set up between your modules are not optimally efficient. This will result in simple-seeming enhancements being prohibitively expensive....unless you start crossing your module boundaries directly. The pressure to do this is too intense to resist, and you wind up violating the modularity of your design in the name of getting it out the door in time.

Sooner or later your system will get complaints that it is too slow, and you will need to open further holes through your module boundaries in order to optimize performance within acceptable delivery deadlines. You will warn that these are quick fixes which must be refactored properly after their release, but the opportunity to do this never comes.

As such changes form layers around your ever-growing onion, the core modules will be come too precious to change. Every little tweak you make to a core module will conflict with assumptions made by other modules, and will cause surprising bugs that are hard to detect in QA testing (since test case count grows exponentially with each new feature). This will result in more demand to fix problems without adjusting the core modules, or by making minimal adjustments to them, which will wind up forcing you to further compromise the modularity of your design.

As the complexity of your system increases, the cost of each new feature also increases, which will displease management and prompt them to say "we used to be able to do this sort of thing in a few hours...now it takes weeks!" They will continue to make unreasonable demands of their senior staff until they push said staff right out the door, leaving the ongoing maintenance of this (now very un-)modular system to the junior level programmers who never shared in the original vision of the system, and hence have no sense for where the module boundaries should be, and just fold to managerial pressure to hack in changes as quickly as possible.

Eventually the slow turnaround times and general bugginess of the system will drive clients to start looking for alternatives. Some brand-new ones will be available (some of which written by the disgruntled senior staff, in fact). Thus begins the end of the product, and of the company if this was their flagship.