Much focus in our industry is on how we can write code faster. We want super productive IDE, high level language and huge frameworks to protect us from the hard reality of building software.
In my opinion it’s more important to find how we can write maintainable code by focusing on readability.
Frameworks
Lots of frameworks promise faster development by “getting rid of” the plumbing, this dirty stuff we don’t want to deal with.
Frameworks might not be too bad if they don’t hurt readability. But as they almost all do, the long term maintenance is a nightmare, because we have a new dependency. It is the classical 90% percent of time to fight the framework for the 10% of things that don’t match our use case.
By trying to write an application faster, we may lost our freedom to update our software when we want. Worse, we are constrained by some naming or architecture convention, making our code less readable.
Property Dependency Injection
The only argument I hear to justify dependencies injection by properties is: it is easier to write. And it’s a really bad argument.
It is much more valuable to be able to understand easily all the dependencies of an object. One of the best solution in an OO language is dependencies injection by constructor. It allows seeing quickly what are the responsibilities of a given class.
It’s really irritating to find out at runtime that I miss a dependency because it is injected via a property, or worse, directly by calling a static IOC container in an initialize function.
Choose freedom
Instead of losing readability with a framework or other antipatterns, we can choose freedom. We must find lightweight libraries to match our needs, and not be afraid to write code. It will be more maintainable than a framework.
It is where a DDD approach makes sense: by identifying the core domain, we know which part of the system must be as pure as possible. But in a more generic domain, using a framework may be beneficial. As usual, context is king.
The core domain is the main value of our software, do we prefer a quick writing, or an easy reading?
The wrong fight
It’s appealing to believe that we should write software faster in order to improve the business we work for. I believe it’s a fundamental mistake. To be faster we need to make the software easy to evolve. And it evolves faster if we can understand quickly what is its purpose.
How many hours per day do we write code?
How many hours per day do we read code?
So why are we still writing new frameworks instead of focusing on clean code and readability?
Thanks Samuel Pecoul for suggesting improvements