Should we Write Generic Code?
In programming, there are two extremes that are consistently travelled by developers. One is to write code that is not extensible, which implements functionality but provides no avenues for extensibility. This is the mistake made by most people starting in the profession.
The other extreme of the spectrum is mostly done by people that are becoming more experienced, but is also a big problem: writing code that is too generic and extensible, without an immediate need.
The Smaller Of Two Evils
It is easy to argue against inflexible code: most people will just point out that if you need reuse the code in another situation, then you will need to change it, and that will make the system harder to extend.
Despite this, as paradoxical as it seems, inflexible code is easier to fix then ultra-extensible code. The problem is that when we try to write code that is extensible, we are trying to guess the nature of changes that will come up in the future. As most of us can witness, predicting the future is not a strong skill of human beings. We are constantly making wrong bets when it comes to write software to satisfy our future needs.
Now, the big problem with code that is more-generic-than-it-should-be is that now we have more code to maintain over the long run — even if the future use that we were predicting never comes. As development evolves, every layer of code will have these embedded functionality assumptions, code that ultimately will never be used. As result, it becomes increasingly difficult to verify that our generic code is working, as there is no real code using those features.
Unit Testing to the Rescue
If you are a fan of unit testing, then you would most probably say that the solution is to create unit testing for all the extra functionality as you write the application. That is in principle a good solution for the problem, but you may be forgetting that unit testing code is also code. It may contains bugs, and the more code we write, the bigger is the possibility of introducing new bugs. So, while writing unit tests for the whole code is a strategy to avoid bugs, it is not necessarily the best way to fix the issue, as it can also become a source of problems.
The whole grail of programming, in my view, is that good software needs as little code as possible to implement its features. More code means more problems, and that is the main issue with generic code: we simply need to spend more effort to maintain it. The shorter code that does only what it needs to do will most certainly be easier to maintain and to understand. As a side-effect, if it is easier to understand, it will probably require less intelectual effort to extend when necessary.
Conclusion
Writing good software is an act of balance. We certainly want to avoid situations where functionality is tied to only one environment, and therefore it is difficult to reuse. However, we also need to guard ourselves against over-extending code with features that will probably never be used.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
