The Maintenance Developer Myth

As a little distraction from writing I was procrastinating on Hacker News and Reddit. The blog post “Why are we interviewing Developers by asking Architect questions?” caught my attention and got me thinking about the term “maintenance developer”. Those mythical species of developers who are so insisting that their work is so fundamentally different from all other things that developers do. As Ted Winslow points out they should not need to know anything about architecture. Others think they don’t influence the code and therefore don’t need training. Visiting a conference is a waste of time, then all they do is maintenance…

It nearly seems as if those developers go to work, spend 8 hours there and go home without any what so ever influence on the code base. What the hell are those developers doing? Do they change the oil? Do they fill up the fairy dust containers? Do they patrol to keep the trolls out that otherwise start eating the software bit by bit?

 

Difference?

Whenever I ask one of those maintenance developers they tell another story. They add new functionality to existing code and remove bugs from the system. They may use an older technology to do that but they do what every other developer does as well: They add functionality to existing code and remove bugs.

Why then use the term “maintenance developer”? They’re developers as every other. Agreed, it may be years since they clicked the last time on “File / New / Project…” but is this little wizard that important? Even on greenfield projects – should they really exist – the work starts as soon as the wizard created the new structure. When the first line of code is written, then it’s just “add functionality to existing code and fix bugs”.

 

Details & Quality!

But that’s not all what we do!” will you hear from the maintenance programmers. The special attention to details and not to break anything is what they’re especially proud of. Granted, this is important. But it is important for every developer in every kind of project. Or is there ever a customer that says “In my project you can select the features as you like and write code as bad as you can”?

To make it even worse: Where will it lead if only the maintenance developers should care for quality and not breaking software? Does this means every other developer doesn’t need to care? Can they do whatever they want without thinking about the consequences of their actions?
How bad would software be in this case? And does anyone really believe the best solution to get that mess fixed is by developers who don’t get any kind of training?

 

Time to say Goodbye

More than 8 years ago the term “maintenance developer” was already the centre of a vivid debate. Jeff Atwood collected in “The Noble Art of Maintenance Programming” different views that are still relevant today.

So far the term “maintenance developer” is only used to divide the developers. In those who matter and those who fix, in those who make the cool stuff and those who don’t get training. I think it’s time to say goodbye to the term “maintenance developer” and start calling them just developers. After all, developing software is what they do.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.