Developer’s Sins: Fear of maintenance

I have met and talked to a lot of developers in my life. I went through the whole lifecycle of software production many times. People have changed, but the projects that have been implemented, are happily still running in production (at least most of them, let’s say :)).

What I have noticed during this period of over 10 years working with the software and people producing it, is that many developers have quite a strange approach to work. In IT there’s this request type called “Fire and forget”, where you don’t wait for the callback.

The same way, those developers wish to develop software, but the support, or maintenance, or whatever you call it, would be good to handle by somebody else. I even know that in some companies, it works like that, they implement and the support is sold to another company, but that’s not a standard. It could be transferred to another team in the company, which happens more often, but I think in the majority of cases, especially if the team is not very large, the support usually is being handled by the same people that have written the software. There’s also the case where people that wrote the software are not working in the company anymore.

If somebody doesn’t want to support his code right after being written, then I see two options: either the code is of good quality and there’s not much to support, or there’s a ton of bugs and support is problematic, but then, who’s responsible for this situation?

On the other side, I could say, that maintaining somebody else’s code, is more or less the same as maintaining our own code written a few years ago (maybe even a few months ago). I know we’ve got our style and we might recognize our code, but don’t tell me that if you open your code written 3 years ago, it’s any better than the code of any another developer. This is maybe even worse because you feel guilty you committed such code 🙂

So if it’s not about who, then maybe it’s more about how?

The problem often begins when resolving a problem generates a big risk and takes huge time to analyze the source of the problem, and estimate the eventual impact of the implementation. The fix or change itself is usually very fast.

So what could it be? Let me think about some examples: lack of proper documentation, lack of unit tests, lack of comments for ugly code, TODO, improper naming, or maybe generally speaking: problems with quality.

Maybe the conclusion is not fully accurate, as things are not usually binary (black or white), but I guess that’s a very high percentage of the cases. And if that’s the problem for our code, then it brings us to the conclusion: why are we producing low-quality code? And if it was somebody else, then it means even more that this person should be maintaining this code – to see, to experience, to learn why it’s extremely important to write high-quality code.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.”

—John F. Woods

Sometimes the situation makes me feel like in the kindergarten. If you ask the developer to write a documentation he’s looking like if you ask him to run a marathon in 35 ℃, but when there’s no or bad documentation for a feature he needs to work on, he’s the first to complain. The same goes for writing tests, code reviews, refactoring  – quite often excuse like “there’s no time for it” is just hiding the fact we don’t want to spend time on it.

In such case, I could even understand we don’t want to maintain such code. Let’s just give the maintenance to somebody else, he is then going to have the problem, once we’re done. At the end of the day: it works, for now.

So we call ourselves Software Engineers, but we wouldn’t like engineers to approach the topics like that when it comes to building our flats, bridges, and offices. We just assume they did everything properly. Not like in this interesting article, right? How are we different if we are proud enough to call ourselves Software Engineers?

There have been loads of articles about quality, technical debt, and other techniques to approach the software development properly, but today I have a very important, yet very simple advice.

Be a responsible developer.

Do the code as if you had to change the functionality in 3 years by yourself. Do care about the easiness of implementation. Do spend time on code quality, write unit tests, spend time on proper documentation. Don’t leave problems in the code so that “somebody will fix it” – nobody will.

An experienced developer doesn’t necessarily implement the code much faster. The time might be the same as for beginner, or even longer. That’s because the time needed to produce a high-quality code takes time, and responsible developer knows that and won’t sacrifice the quality for minutes.


What if you do your code properly, and you have inherited a legacy code for support? Well, I’m sorry for you 🙂

Jokes aside, to me, if you’re a responsible and professional developer, it’s simply your job to make this situation better. That’s what you’re paid for. Don’t push this responsibility to somebody else. It’s the systematic work you have to put when working with the code, to write tests, to document, to refactor, to leave the code always better. Don’t fall into the trap of Fear of refactoring. Don’t forget that Rome wasn’t built in a day.

I know that might be a difficult job, but hey, you are not hired to work on easy tasks. Be the guy that people want to trust, that everybody knows is responsible for his job and is worth paying the money.

Become a true engineer. Put your heart in the job.

Stay focused. Stay positive. Stay responsible.

Advent of Blog

This is my seventh post in the series of Advent of Blog 2017. I will be publishing one post per day as I mentioned in
first post of the series.

Stay tuned.

One thought on “Developer’s Sins: Fear of maintenance

  1. Pingback:

Leave a Reply

Your email address will not be published. Required fields are marked *

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