Software Maintainability – Off the Shelf vs. Roll Your Own
Maintainability is essential to software quality. There are many aspects that come into consideration while building maintainable software. One of them is – building your own utility or infrastructure vs. picking up something ‘Off the shelf’.
The problem
Often times, teams build custom home grown frameworks that solve problems not very unique to their business solution. This problem can be a common one, like navigation, UI generators, caching, data access, reporting etc. Generally the intrinsic details of the implementation are known to a limited few, while the rest have limited functional understanding and outdated documents. Tho cost of maintenance starts to hurt as the technology evolves.
How did we get here?
There are a few common reasons for it in the cases that I have seen. The most important is the lack of down payment for research. It seems easier to start designing something and putting together quick samples and PoCs to see it work. Since this is a creative process, it is appealing and interesting too. The other option is spending time on looking for existing tools, understanding & evaluating them, checking the cost, checking associated licenses and discovering market adaptability. That sounds like a lot of work and is difficult to estimate.
How bad can it be?
Once we start down, what appears to be the feasible path of building the custom framework, we try to make it as flexible and extensible as possible. We might start with a framework that helps with routing. Given the framework is truly custom, written from scratch, we try to think of possibilities beyond the requirements. So the framework starts to accommodate caching, user activity logging and maybe authorization too … why not? It’s all custom code; we can make it do anything, right?
Over the months and years, it becomes hard to explain to the new team members why this navigation framework is auditing data too, especially when the application platform itself provides many solutions to the problems that this custom tool solves (or claims to solve).
The custom solutions that live outside the development boundaries can be more restricting. I have seen custom regression / deployment tools, in which organizations made good investments over time, but slowly boxed themselves into it. As a result, adapting to the emerging DevOps techniques becomes very difficult.
Some solutions
Understanding the problem itself is a solution in many ways. It will push you to look out for exiting products, within / outside the platform. Check with other teams to find out how they have solved the same problem.
The original problem that led us to this path was lack of the time available for research and discovery. It is never easy to come up with a down payment all at once, but smaller planned buckets make it possible. Create a technology radar of frameworks and relevant trends. Many teams maintain a technology radar and allocate budget for the research work on a continual basis. Not only does it keep their applications using the latest and greatest technology, it also attracts the right talent. Think about it, would your team be excited about understanding a data access framework custom written 5 years back, or would they prefer using proven tools like Entity framework or Hibernate?
Use the online forums to seek information and opinions. I have often seen people a little hesitant about posting questions online. Do not hesitate to ask the online dev community. You might be surprised how enthusiastic people can be if they are passionate about a certain problem. You will not only be helping your team but many others who search for answers to the same questions.
Conclusion
There will always be a situation when you wouldn’t find the right solution and will attempt to build a custom framework. However, doing that should not eclipse the business problem you are trying to solve. The focus should always be the unique business solution as opposed to spending time replicating existing tools and frameworks. There is never a perfect set of tools for any problem, but if you pick a product that solves your needs, you might be writing / testing / maintaining less code and reducing maintenance overhead.
