Developers Are the Problem, Not Monoliths

07.02.2019 by Jens inDevelopers Life |Learning

In a recent post I wrote about why you should not use microservice I mentioned on the side, that developers are the problem for the nightmare monoliths. And not only for that, for much more.

Let’s start with the monolith view. A monolith becomes a nightmare when it eventually turns into a large bowl of spaghetti. Changing one tiny thing at point A it breaks something at point Z. And when you try to fix that, you soon have the whole spaghetti on your fork.

The interesting question is, why does this happen at all?

Is it a problem of the pattern? Will another pattern fix the problem?

The short answer is no. It is not a problem of the pattern, and a new pattern won’t fix your problems if you don’t fix the cause. If you keep the same root cause, any new endeavor will fail too.

Do you really expect that with the same team and another pattern, you will succeed?

Humans are complex. A team is a complex organism. And dev teams are no different.

So, why does this happen?

It’s not a single cause. It is a combination of multiple.

Here are the most common I’ve encountered in the wild.

Inexperienced Devs

One of the worst things that can happen is that a bunch of fresh junior devs is developing it and no one around to guide them. Inexperience is typical and not bad per se. But if the hole team is it, it means all of them are learning on the project how to build it. And they will make mistakes, many, many, many mistakes. Which is normal in a learning process but a nightmare for the project. Results I’ve seen are missed deadlines and un-maintainable codebase. Not to speak that the biz side was never happy.

A Team of Solo-Workers

You got a couple of devs on your team who know what they do. The project is split that everyone gets its puzzle piece with minimal interfaces or overlaps. Now ever dev codes and works in his or her style, good or bad doesn’t matter. All they see is their tiny piece and that what they care for.

I oversimplify now because the dynamic at work is quite complex, and part of the negative behavior is covered later. The results are multiple implementations of the same logic, logic in places where it does not belong, broken interfaces (they are never as defined earlier), bitching and moaning, whos’ fault is the error and who should fix it.

Not Understanding or Caring For Complexity

I wrote about that on my newsletter many times. Complexity is everywhere, and as a dev, you need to handle a lot of it. This skill is even more important than knowing the syntax of your language of choice.

Before making changes or implementing new features, think about what is affected by that change. What implication might it have? Where is the data flowing along? Does it make sense to place my order logic into the PersonController? What are the consequences if I use that method/service/X? <– That one is overlooked A LOT. Look for data loading, side effects it might have, etc.

Testing New Languages, Frameworks, Patterns in a Project

Learning is great. Learning is fun. But not on a real project with a tight deadline and no one on the team has ever worked with the new tech stack before. Oh, that framework looks nice, I’ll do my next client project with it.

NO!

Client or mission-critical projects are not a place to toy with new technologies. A team should use proven techniques they have experience with. And if a new tech might actually help, make it clear to everyone involved that this is new and there will be mistakes.

I’ll Implement That Quickly

It’s not even about tests. The general problem with the “I do it quickly” “approach is that the dev will overlook the consequences of his doing. He will not think much about but only care for fixing the thing asap. Like loading additional data in a central service which is just needed in his single case and he could implement fast. Damn, he just overlooked that it was intentionally left out in the central service and his change broke performance on another part.

Hey, it is your job as a dev to keep that maintainable. The only exception is throw-aways-software.

Devs Write Code Not Business Guys

If you listen to the bitching of devs, it is always the business guys, project managers or whoever who is the culprit for that the software is so bad. Never them. The others are.

But know what, the project manager does not write the code. You as a dev do. So, it is your job to do it right. The project manager did not add that spaghetti code. Nope, a dev did.

Yeah, sometimes you don’t have the time and need to hack it in. So be it; you still did write the code. Time is a constraint, make the best out of it but don’t bitch about others.

Ignoring Rules, Being Sloppy and the Wrong Laziness

You have rules in your team, ranging from code formatting rules to handling change request, etc. Yet, there will be a bunch of devs who will right out ignore those.

Was on a team with code formatting rules which had to be checked in a code review. Yet, the same devs always had the code formatted wrong. If a rule is stupid, change it.

Being sloppy and the wrong kind of laziness go hand in hand with the “I’ll do it quick” fraction. Same effect, different cause.

Saying Yes to Everything

If the biz says, “Jump,” many devs ask “how high?” or just do it. It is the same with requirements or workloads.

If the requirements are shit, have logical flaws, missing aspects or just don’t make sense at all, talk with the biz. But don’t speak dev gibberish with them, speak in their language about the problem.

Same with the workload. Don’t switch tasks on a whim because one project manager told you it needs to be done. This is notorious for a single team handling multiple projects with different project managers. It is especially bad, when you have “Yes, Sir” types of devs on the team. The results are additional felt pressure on those devs, which tend to quick and sloppy work. Resulting in shitty code.

Wrong Decisions

Making the wrong decisions and not standing behind it. Overplaying it or just denying it.

A recent example makes that more clearly. Take a dev team, who build a new app from scratch - greenfield. They chose a document store but modeled their domain objects in a relational way. Now X features and iterations later, the performance went downhill… Yet, no one admits the wrong architectural decision. But anybody complains about it - even the devs. Bad monolith.

Yep, they definitely made a wrong decision, and in this particular case it was a combination with “New Tech on Client Project.”

Final Words

During my decades as a dev, I’ve seen many of those causes and the consequences. I’ve done plenty of them myself, and I can tell you one thing. If you don’t change yourself, you’ll make the same mistakes every time again. Resulting in the same problems. No matter if building monoliths or microservices.

It is not the tech, it’s the devs.

Want content like this in your inbox each workday? No BS, spam or tricks... just useful content:

Developers Are the Problem, Not Monoliths