Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
Hi. I’m Dean, and I was a maintenance programmer.
I’ve just spent the last two days refactoring the infovark storage and retrieval API. It wasn’t that anything was broken, exactly, it was just that it was… messy. There are a lot of things I should have been working on instead, but I couldn’t resist tidying up the object model a bit. It’s a weakness of mine.
You see, “maintenance programmer” is generally considered a pejorative label in the software development industry. Programmers that do maintenance — minor bug fixes, performance improvements, functionality tweaks — are generally on the lowest rung of the development team.
That’s how I got my start in software. My first coding jobs were technical support and troubleshooting gigs. You can ask anyone who’s worked with me on a development project, and they’ll tell you I’m fastidious — some might say fussy — about the structure of my code. And, truth be told, I’m picky about everyone else’s code as well. Since my first experiences with programming were maintaining large codebases written by other people, with no specifications or even a user manual to go by, I’ve developed certain habits of mind.
If great hackers are the poets of the software world, then maintenance programmers are the copyeditors. Great hackers produce elegant code. Their deeds are legend in the computer science community, and some have passed into history. Some are so good they’ve been celebrated in free verse. Their code soars in cathedrals of light, pure in its mathematical beauty.
By contrast, the code churned out by the maintenance programmer is solid, workmanlike, and perhaps unimaginative. But it works and will continue to work. There won’t be any odes sung to the maintenance programmer, but at least a few respected developers out there, like Eric Sink and Jeff Atwood, have spoken up for us. There’s even How to Write Unmaintainable Code, a humorous treatise on the many ways to drive a maintenance programmer crazy — and a tribute to all of us that have suffered at the hands of sloppy development techniques.
So we’re beginning to get some respect. And I’m proud of the work I do. I realize that being a stickler about naming variables properly or commenting logical branches only slows down development. But I take comfort in knowing that my code will stand up to some abuse out there in the real world.
Do you think you might be a maintenance programmer, too? Here are the seven warning signs:
Sound familiar? If you get the same feeling of delight at sorting out spaghetti code as you did reading Eats, Shoots, and Leaves, you might be a Maintenance Programmer. There’s good news for you, however: You’ll always have a job to do. Because no matter what happens in the computing world, there will always be code in need of a rewrite.
No related posts.
5 Comments
Ben Tremblay
heh … I do “maintenance” on technical documents. Also on broadcast station studios. And long distance telephone systems. And 4000 mile-long SAC/NORAD troposcatter systems.
I’ve made a living cleanup up engineers’ gack.
;-P
05 Feb 2008 10:02 pm
Ben Tremblay
p.s. Our avionics project was a microwave landing system … R&D shortly before GPS came out … fly a plane past the decision point in a blizzard and have it miss the squishy stuff on either side of the tarmac.
Mandate #1: thou shalt not transmit false data. If the data’s there, then the data’s good. If the data’s not good, the pilots get silence.
Anywhoo, that called for a lot of realtime monitoring (no biggie) and equally realtime signal analysis (holy.shiet.you.must.be.kidding) … and BuiltIn TestEquipment. (Shall we go with AI? or fall back on expert system *Yoikz! Zounds! Gadzooks!*)
There was a lotta stuff happening every second. Which meant some heavy-duty programming of the best programmable devices available.
My buddy Harv was a whiz. I mean a wizzard. I mean really. Dewd wrote C and assembler that hopped and popped and jumped and spun … truly impressive.
We had to let him go.
He got a job with some sorta Navy SigInt project. And everyone was glad for that.
We couldn’t keep him.
We could read his code.
We just couldn’t undertand it.
He was that good.
It was mind-bendingly dense … parsimonious to the point of cryptic. And that was the catch.
I’ll always remember Harv. “Unmaintainable” but brilliant.
05 Feb 2008 10:02 pm
Fighting the Framework « Infovark Underground
[...] I’ve mentioned previously, I’m someone who likes his code logical and tidy. While I’m just as guilty of playing the F5 game (a.k.a. “try it and see”) as any [...]
Tools: Beyond Compare 3 « Infovark Underground
[...] my roots in maintenance programming, I’ve used a wide assortment of programming tools. Maintaining legacy code is not much fun. [...]
Review: Framework Design Guidelines « Infovark Underground
[...] they should. That’s probably my roots as a maintenance programmer [...]
What do you think? Leave a comment