As a software development company, we have a policy of maintaining the code we’ve built. We feel it’s our responsibility to provide this to our clients. On the other hand, maintaining code we didn’t build and living with consequences of those decisions we had no hand in making is very painful.
As a programmer, it is a fact of life that you will spend more time maintaining and modifying code than writing your own from scratch. Once a block of code has been written it is usually straight into maintenance mode and programmers are testing, reworking, refactoring, and tweaking until it operates as expected and reads well. This is part of the process.
As an app development company, we have a policy of maintaining the code we’ve built. We feel it’s our responsibility to provide this to our clients. On the other hand, maintaining code we didn’t build and living with consequences of those decisions we had no hand in making is very painful.
Why do prospective clients ask us to work with someone else’s code?
The main reason is that they don’t have anyone else. Usually, these companies have a piece of software that was created by someone who is no longer working with them. They are left with a system (hopefully a fully functioning one), but with no one to address issues or enhancements as they come up.
Another reason they approach us is because they have a partially working piece of software they would like completed and think it will either make our job easier, shorten the timeline or save costs.
Why is it so painful?
Working with another person’s code can be difficult, frustrating and confusing. How frustrating is it?
It very much depends on the quality of the code, the scope of the work and the documentation provided.Most of the time though, the code we’ve received is years old and has been updated numerous times by many different developers with their own standards and styles. The code quality has not been great, including redundant code that was never removed, no formal documentation, and out of date comments.
Software maintenance is pretty complex, challenging stuff. To make any changes, we need to fully understand why the system behaves the way it does and how it does it. Even once we are confident that we can make changes without introducing bugs, there will be times that without realizing it, the code we are changing affects other parts of the system. This is primarily seen in complex, large systems or in systems without tests. Tests ensure that the changes developers make do not break the system.
What problems do these projects bring to software development firms?
In most cases, we need to incur the costs of fully understanding the system as clients don’t see why a simple feature costs as much as it does. Additionally, for most companies it is more important having functioning code than having code that is clean and easy to maintain. Therefore, refactoring (the process of restructuring existing computer code without changing its external behaviour) is money wasted.
Why spend time redoing something that is already done and potentially introduce even more errors?
Because it reduces complexity, and improves code readability, maintainability and extensibility. Usually these types of companies aren’t computer/software companies so they don’t have the technical background to know that sometimes you need to invest in these type of chores.
Other times, some companies will claim that certain features operated correctly prior to us working on them. Again, due to the lack of documentation, it is hard to prove or disprove. Maintaining software very well could mean getting daily emails from users about potential bugs (a lot of them being misunderstandings on how their system works).
So what to do?
We recognize it’s a tough situation for a company to be in. There are a lot of companies whose main offering is supporting existing systems. They are good at it and make a good living from it. We are just not one of those companies (learn about the kind of work that excites us).
Most developers have an unnatural knee-jerk tendency to want to rewrite for the sake of rewriting. At some point though, you will need to decide whether or not it is worth it. If the foundation is not sound, no amount of routine maintenance is going to fix it.
