I love tech. Look at all the fun stuff that’s happening in this development wonderland at the moment.
We have libraries to do everything under the sun. Persistence, web-apps, security, code generation, presentation, remoting, messaging, concurrency, XML processing, testing, containers, you name it. In Java-land, opensource seems to be dominating the market and we’re even starting to see books dedicated to the subject (end of shameless plug).
It’s easy to get seduced by the sparkle of how these tools can make magic happen quickly. With these tools, a system can be delivered in record time. Win!
But delivery is really just a short term win. After delivery comes maintenance and this is where most development teams get stung in the long term. It becomes harder and harder to add or refine features as time goes on. Chris Matts pointed out that over the life of a project, the cost spent on development is insignificant compared to the cost of maintenance.
It’s impossible for a sexy library alone to make your code maintainable. Using JUnit or an AOP library will not solve the problems. It’s the *techniques* that complement these that make applications more maintainable. The tools are just the icing on the cake and you really don’t have to use them.
The techniques are unfortunately less seductive than the tools, yet far more important. I often find myself answerless when faced with explaining the benefits of separating the interface from the implementation, using mock objects, inversion of control, aspect oriented programming or avoiding statics.
In most cases, I found there is no benefit of using a technique in isolation. Instead, they benefit each other. It’s the relationship between the techniques that are important and they all support one thing – maintainability. The relationships are patterns.
So, I have a theme for upcoming posts on the blog: *maintainability patterns*. What techniques we can employ to make code more maintainable and how they relate to other techniques.