We Really Don't Know Jack About Maintenance 260
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."
Wait a second... (Score:1, Interesting)
Maybe I'm too naive, but is there REALLY that much spaghetti code these days?
Different Kinds of Companies (Score:5, Interesting)
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:Wait a second... (Score:0, Interesting)
Modularity is one of those things that sounds great when you're an academic, when you're a manager who has never touched code, or when you're an accountant.
Such people think of real-world code as being completely interchangeable. To them, it's nothing more than the nuts or bolts they'd see at a hardware store. They think that programmers just grab some of these "modules", some of those "modules", put them in the same source file and BAM, we have working software.
Of course, reality gets in the way and makes their theoretical world disappear instantly. Such modularity typically comes at a great cost. Even when using dependency injection and techniques like that, modularity is always a pipe dream.
Not only PHB (Score:3, Interesting)
They just could NOT get their minds around changing external circumstances, working in tiny groups, version control, V2... was easy as was getting their all 3 systems updated. Pre/Post/Co - requisites, SCM, package management, bug-tracking were all to come as the world started to really use this stuff and they also had no communication disconnect, because there were less than 1000 and they all knew each other,
Yes its a HUGE problem, but unfortunately does need real understanding!
Re:"Everyone knows maintenance is boring" (Score:3, Interesting)
"... some righteous macros to make the code more readable..."
OMG, somebody fire this jerk. In most cases adding macros MAY make the code more readable for you, but the next poor guy who comes along can no longer look at that section of code to see what's going on, but must now combine the code he's reading with a macro that he can only assume was implemented properly in the first place.
And if by "righteous" you mean some complex and convoluted code boiled down into a single line... then you should not only be fired, but shot.
Unless the above should have been in [sarcasm] tags, in which case, the immortal words of Miss Emily Litella apply. (grin)
Re:Wait a second... (Score:3, Interesting)
No modular system survives version +0.1.
You have a perfectly modeled modular system, and you really think you thought of everything. Only to notice that someone comes up with some problem you didn't take into account. So what do you do? Redesign the whole modular system, unravel all the finished modules and rework them to fit the new interfaces you have to design? Nah, we can handle a single nonstandard data handoff...
Do I have to go on?
Re:Different Kinds of Companies (Score:5, Interesting)
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.
Re:Different Kinds of Companies (Score:3, Interesting)
we're just beginning to rediscover it." (Score:3, Interesting)
In this age of 20yo CEOs and single-quarter companies it's hardly suprising that most software is no better than a rigged demo.
Just make it shiny enough for someone to buy the company and then let their support staff of MS trained monkeys deal with it
Then we have the "artists" (in both the software and hardware field) who have survived for twenty years without "all that sh1t". Course, like the CEO, they've gone on to their next challenge long before the chickens come home to roost. And it's not their fault everyone else is incompetent, is it?
I continue to be amazed, on a weekly basis, by the complete lack of experience shown by the actions and products of very large companies.
Oh, I reject the claim that
The author has obviously never maintained hardware: it has bugs, patches, upgrades just like any other part of your system.
Re:Wait a second... (Score:4, Interesting)
I blame hard deadlines and crunch time, but I'm not sure if that's the real cause, or if it's just a different class of programmer writing video games. The excuse *used* to be optimization, but I don't think that applies nearly as much anymore.
I think the game dev industry is growing up. Part of it has to do with the fact that a mature codebase is pretty valuable nowadays, and modern games are so complicated, those who don't take good software development processes seriously end up with a technical disaster, and it tends to show. It's very rare for a game to be written completely from scratch these days. When I was started, it wasn't all that unusual to start over for each new successive generation of games. Some of the base libraries I'm working on are nearly a decade old - about when the company I currently work for was founded. They're well-tested and highly optimized. We'd be insane to toss these out and start over.
You also have to differentiate between engine code and game code. By it's nature, game code is essentially a one-off project - essentially single-purpose code. Keep in mind that unlike commercial projects, if the requirements for version 2 of the game change, the code can be rewritten. There's no need to preserve old features or functionality unless the new game requires it as well, as each version of the game is essentially a new fork. To some, it looks sloppy to see hard-coded gameplay features, but it makes a bit more sense when you think about it in that light. MMOs do have it a little harder in this aspect, being so long in continuous development, so we have to think about things like preserving file format compatibility and such, similar to other commercial apps.
Engine code is typically treated quite a bit differently. It has to be much more robust than typical game code. A number of games will be using it, so the code has to be both modular and highly optimized, as well as being fairly general purpose. Obviously, that's a fairly difficult combination, so developers typically put a lot more effort into engine code, and tend to be more protective of it.
Oh, and good heavens, yes, we still have to optimize the hell out of our code (oddly enough, I've been doing that all last week). It just happens more often at the architectural and algorithmic level rather than at the functional level like it used to. It's true that we can get away with a lot more, but... we're also doing much more complicated things.
Re:"Everyone knows maintenance is boring" (Score:4, Interesting)
This is why you refactor the code alongside the original. Fix bugs in parallel. When there's a new bug, you roll back to the old, non-refactored code and see if it goes away. If so, you stay on the old, crappy code until you can fix the new, cleaned up code. Then you swap back to the new code. You repeat this testing phase until switching on the new code doesn't introduce any critical regressions, then continue living on the new code for a few months before nuking the old code.
Yes, this is slower than doing development on a single version of the code, but it's a short-term penalty until the code is cleaner and more flexible, at which point you then make up for the period of slowness in the minds of your bosses by proceeding to successfully add twelve new features in a single week---you know, the ones that have been punted for six years because they were too risky to make in the current fragile code base.
The trick is to alternate between rewrites and enhancements. Don't stay focused on rewrites too long or you'll seem unproductive. Don't ignore it for too long or you'll find yourself blocked and eventually become unproductive. The only way to survive is to stay somewhere in the middle.