When you’re learning to code, you normally focus on making the thing do what you want it to do. Once you have that under control, you focus on making it work faster and more efficient. Then you actually start to more actively use and design patterns and you start to appreciate their beauty.

And that’s it for most people, at that point you’re probably a senior developer with good coding practices. But that’s definitely not the end of the road. Depending on your work you may actually have to think a lot on Scalability and that opens up another world of possibilities that still now a days is not “solved”, and everyday there’s a new framework, persistence layer or caching technology seeing the day of light.

But, still, the road continues with what I think are often forgotten or non-priority concerns: Maintainability and Shareability

Maintainability

Hasn’t it happened to you that you look back to code that you wrote a year ago and go: “ok, why did I do this THAT way?”, or even worse, you look at some one else’s code and just don’t get what did they do… This is what I refer to with maintainability: The ability to maintain and evolve an existing code base.

For this I’d stress three good practices that can help keep your code maintainable:

Keep it real: The best way to make your code maintainable is to keep it close to the business needs. In this sense Domain Driven Design is a powerful tool because it creates a common language that enables developers and business experts to communicate effectively, and as a side effect allows the developer (when in doubt) to go ask a business expert what is the code doing and is therefore great for maintenance.

Be verbose: Verbosity goes a long way into helping understand what code does. When I say verbosity, logging is of course the first thing that comes to mind, but the concept expands also to having correctly named variables, methods, classes, etc. But there’s more, in these days where everybody uses IoC and DI frameworks like Spring, sometimes it’s hard to follow how things are wired together; don’t take me wrong, I like the @Autowired annotation, but I don’t like so much @Component/@Service. I prefer to declare beans explicitly in the .xml files.
It’s a bit like the when you’re studying and writing things down actually helps a lot to memorize and understand them.

Refactor: Last, but not least, one the best practices for maintainability of code is to do continuous and incremental refactoring, because honestly it’s not always possible to do it right the first time (because of time constrains, changing business rules, being human, etc).

Shareability

Shareability is the next step. While maintainability allows you to evolve a code base with the business needs, shareability is what allows your code to be able to accommodate not only your specific needs, but other team’s and other businesses’ needs without making the code base a mess.

A great example of this is the Spring framework itself: The way concerns are isolated and interfaces are defined makes the framework amazingly flexible for a very wide range of uses.

This is the most complex level of abstraction to achieve as it implies distilling the essence of each peace of code, carefully designing interconnections and thinking of uses you haven’t thought possible. But it’s also the most “fulfilling” level of coding: If you’ve ever had to implement a new feature and you’re afraid it may be a big change because it deviates a lot from the existing use cases, but it turns out that the solution fits naturally in the existing code, then you’ve just experiences shareability saving the day.

Is this last “level of coding” what has been driving my attention lately, and where I’ve spent some time thinking of alternatives.

In following posts I’ll describe a programming paradigm and framework I’m developing that I think helps you get to this level of coding.