When business does indeed sucks

In a recent article I explained why I think we should all be Domain Driven.
I get some interesting feedbacks on the “business sucks” syndrome.

Indeed in this previous article my point was to make technical teams aware of the necessity for business to change in order to constantly fit its market as much as possible. But sometimes business does indeed suck.
Let’s take a few examples I’ve met in 10 years as a software developer.

The never-ending prototype

One of the most common business error I’ve met is the fast hacked prototype that goes into production, and then evolve in a maintenance nightmare because you know… It works, why should we rewrite it?
To be fair, this is one of the hardest things to do when you start a new business. The first step is to look for a market fit. This can take years, and you must be very fast to test your hypotheses. You are sending many prototypes in production, and most of them will only live for a few months. At this step this is perfectly fine.
Of course the problem arises when, finally, you find your market fit. The growth is here, more and more customers are using the prototype. This is when courageous entrepreneurs should throw all the technical stuff, and write it from scratch with more money and knowledge. More money because growth means that we can get money, more knowledge because many technical limitation from the prototype will be clear, and a more robust product can be built from this knowledge. As Francesco Cesarini would say: “A programmer will fully understand a problem only when he fixed it at least once”.
What happens instead is that the money is used to growth even faster, the prototype has to scale even if it’s not done for it, and the technical team has to deal with many domain and technical problems that should have been avoided.
Here starts the famous “we don’t have time for tests, we have to deliver”.

Head in the sand policy

This error concerns mainly big corporation. But I’m sure you already were as surprise as me to see how fast politic can become important even in small companies.
The company is big enough to have a few layers of management and different services. Because the top managements want to keep control of the company, he’s requesting the famous KPIs. Each service has different KPI, and quickly enough, most employees understand that they can earn more money by targeting the KPIs than by trying to achieve the best possible product for their customers.
Worse, KPIs might be highly destructive when the KPI from a service leads to more burden for another service.
For example, if one of the KPI for the support team is to take as many call as possible, they will quickly classify lots of tickets as critical bugs to be managed by the technical team. Just because it’s faster than trying to understand what happens to the user.
As a result the technical team might have a more work and the global delivering flow of the company will be slower.
Each service prefer to keep their head in the sand rather than trying to collaborate with other ones.

Enterprise Standards

Another widely spread error is the standardisation spree. Usually in the name of costs hunting (even if it’s more about power and control, because in the end it often cost more than local auto organization), the company imposes some methods, tools and/or architectures, without knowing if it makes sense for a given context.
For instance a policy will enforce all the teams to work with SCRUM. Or they will impose a common integration platform for the whole company.
It often happens when management confuses practices (SCRUM, Unit tests, continuous integration…) with principles (being more agile, code quality, fast feedback…).
Many consultants actually increase this confusion and deliver what they (think to) know instead of what the company need in its context.

So should we be domain driven when they suck?

I think my point in the original article is still valid. In the end the problems I described here is just that sometimes, the business itself is not Domain Driven. In the sense that they are looking for immediate profit or power and control instead of caring about the domain.
Thus we should all be Domain Driven, especially the business part of the company. And writing it like that is a bit depressing, but yeah, quite often the business part of the company does not really care about the domain itself.
In this case, we should help them to be more Domain Driven, or just leave them and go work in more healthy environment 😊

 

Dry should not be technical

Do you know the “I talk about it so often that I believe I already wrote a blog post about it” effect? It happens when you talk about something so often that you are sure to have a blog post somewhere to explain it more deeply 😉
It happens to me recently about DRY (Don’t Repeat Yourself). In a twitter conversation where I once more had to explain why DRY should not be technical. I’ve looked for my blog post about it. Just to find that it doesn’t exist yet… Thus, here it is.

DRY ?

According to Wikipedia, DRY is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
One of the main arguments for avoiding redundancy is to improve software maintenance. It seems great right? If you have to modify the code in two places instead of one when you want to change a behavior, you increase the risk of error.

Coupling ?

According to Wikipedia, coupling is a measure of how closely connected two routines or modules are.
Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

The main issue with DRY when apply dumbly is that it increases coupling (which is a code bad smell). Because, sharing the same code between two things create a coupling between them. Too many developers consider that two identic lines of code in the system must be merged and shared into one, because we want to be DRY.
The key to have a smart refactoring in order to be DRY is to care about cohesion.

Cohesion ?

According to Wikipedia, cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves.

If we share code between two modules with low cohesion, the result is a dramatic decrease in maintainability. We take the risk to break the second module, each time we want to change something in this shared code for the first module.

DRY Should not be technical

An easy way to avoid this pitfall is to consider the business concept of what you want to share.
If the business concept is the same for the two modules, you can share it with less risks, because it should evolve for the same reason in the two places.
If it’s just a technical concept, sharing it may be dangerous, because both modules will probably need different updates depending on their use cases.

Of course it happens because, no matter if you know/want it, you’re Domain Driven. It means that your module will evolve because of business requirements. Low cohesion means the two modules have different business purposes, then will evolve very differently. And we don’t want to share something between two things that evolve very differently.

Let me recap

  • To be efficient, DRY must be combined with high cohesion (and few people remember that)
  • An easy way to detect cohesion is to care about the business goal of each module

I do believe it’s one of the first good practice easy to apply that can radically change your code maintainability day after day.