Waiting For Football

This post was prompted by a number of Twitter posts that were discussing if developers thought about who would be maintaining the code they wrote.  Of course the answer is “it depends” as any good consultant will tell you.  No two developers are the same.  Some are more aware of the consequences of their decisions than others.  The real question is what should your goals be as you are developing?

The main trade off we struggle with are speed to market versus maintainability.  Every project is under time pressure and every organization struggles to keep maintenance costs down.  How do you strike a balance that gives you the best return on investment?

Thankfully many of the coding practices that make a piece of code more maintainable are patterns that can be learned and honed to the point where they do not impede progress adversely.

On the other hand, many of the abstractions used to make code more unit testable, such as dependency injection, also drastically increase maintenance cost.  This is especially true as your object graphs get deeper and each dependency relies on another above it.  The tests help greatly with making sure that you don’t break specific scenarios when you change code, but finding a new bug and the right place to add a new feature have a large increase in cost as the abstractions make understanding the code paths challenging.

They way I see it a balance needs to be struck between maintainability, testability and time to market.  How much weight each of those factors have depends on the size of your product, your market and your staff’s capabilities.  Review your company’s priorities and learn to leverage your tools and processes to match those priorities.  In the end this is a game of try, learn and repeat.  Keep your head up and keep improving.