Professor Beekums Blog


Follow Professor Beekums
follow professor beekums on twitter add the professor beekums rss feed

Don't Outsource Software Maintenance

A friend once told me that they work at a company where the maintenance of software is outsourced. That means their in house developers only work on new features. Bugs and such are handled by an outsourced team.

I can only guess as to why this company chose to do this. Maybe they think it’s more efficient. Maybe their developers just refused to do maintenance.

Regardless, I was horrified. This is one of the worst practices used to manage software projects. My face made weird contortions and this didn’t even have any effect on my life or my work. It is upsetting that the state of the industry still allows this to happen anywhere. There are many reasons why this is an unacceptable way to handle software development. Let’s start with operational efficiency, which is actually the least of the problems here.

The original author is almost always going to understand a piece of code better than someone who joins the team. It takes time for someone to jump into complex code and understand how it works. Unless the original author spends a great deal of time explaining things, the developer jumping in will never understand that code as well.

Since the incoming developer does not understand the author’s original intent, they may end up making bug fixes that are extremely sub-optimal. Those bug fixes may work to solve an immediate problem, but they could make the overall system likely to have more bugs in the future. Worst case, these bug fixes will create different bugs in the code that the incoming developer will not notice at first. This is all on top of the fact that the incoming developer is going to take exponentially longer to solve bugs than the original author.

That can be solved with good communication between the original author and the incoming developer. That kind of communication is likely to happen when the two are on the same team. That kind of communication is less likelier to happen when the two are on different teams at the same company. That kind of communication almost never happens when the two are on different teams at different companies.

A slightly larger problem is the resourcing issue: Do you find cleaning up someone else’s mess to be a glamorous job?

Probably not. Neither do developers. You may be able to trick a good developer to do this kind of work for a little while, but they are going to want to do something more interesting eventually. Since good developers are in extremely high demand, you’re going to lose them pretty fast. That means you’re stuck with developers who are mediocre at best doing maintenance work. You may think you can outsource that and make it another firm’s problem. Yet, if they can only hire mediocre developers and you hire that firm, then it becomes your problem.

Let’s not forget that while software maintenance is not glamorous for developers, it is extremely critical for a business. Do you like using buggy software? No? Neither do I! We would probably stop using it.

Fixing bugs is essential to keeping the users of your product, aka the people giving you money, happy with your product. You want good developers helping to keep your users happy.

That leads us to the worst part of outsourcing software maintenance: the cultural problems that get set in.

A company that outsources software maintenance makes it seem even less glamorous than it really is. It makes the statement that reading user feedback is not important. That fixing issues users have with the product is not important. That making users happy is not important. Only new features are important!

Not many successful companies got to where they are by just building new features though. Iterating, improving, and fixing existing features is how they kept their users happy. It’s essential to growth because it is much cheaper keeping an existing user than it is to acquire a new one.

The other cultural problem affects developers more than companies. A lot of software development is subjective. Many developers realize that an important part of their job is to make their code easy to maintain. But how will a developer know if their code is easy to maintain or not if they never try to maintain it? How can anyone get good at a skill without getting feedback about whether something they did was effective or not?

Developers who don’t maintain their own code won’t understand which coding practices are likely to cause bugs and user pain. They won’t understand which coding practices are likely to cause pain for other developers who have to work with that code.

More importantly, developers who don’t maintain their own code don’t feel a responsibility for the quality of that code. They not only don’t know how to make maintainable code, but they don’t care about it either. They develop a false sense of their own importance because they think their lot in life is to make shiny new things. But in the end, they will write worse code than developers who do their own maintenance. That will negatively affect their careers in many ways in addition to providing less value to the companies they work for.

Some developers may enjoy a situation where the maintenance on their work is outsourced. They may even convince their managers that it’s a good idea. In the end though, no one benefits from outsourcing maintenance. Not the developers. Not the company. And most definitely not the users.

share on twitter share on linked in share on reddit share on facebook
Hi there! I hope you enjoyed this post.

If you did, I'd appreciate it if you took the time to check out my product: Dynomantle

Do you struggle with organizing notes, thousands of bookmarks, emails, or other digital stuff? Do you feel bad because you can't copy the habits of "productivity gurus"?

Dynomantle can help. It is a knowledge management tool designed to work with your existing habits. You don't need new habits. Dynomantle works around you rather than have you try to force yourself to work around a tool.

Signup for free!
Sign up for the Professor Beekums newsletter for updates on new posts!
Close this