At one of my previous customers, a developer once asked me what I do when a client chooses the quick & dirty solution after being confronted with different options.

The story behind it was that some members of the team were frustrated with the technical choices their immediate managers were making. When asked for an analysis of a feature, they would propose a solution that involved clean code, modern standards, tests, etc. In short, the ideal solution.

But they would also add an alternative: the quick and dirty solution. This could be chosen if the business preferred to have the feature quickly. But developers warned that it would lead to technical debt.

What do you think the managers always chose?

Of course, they always chose the quick & dirty solution, which frustrated the team. They asked me how to avoid this, how to make it clear to the managers that they should choose the long-term solution for once.

How Do Managers Think?

Managers being a broad term here. This might be your product owner or project manager or team lead. Basically someone with less or no technical skill and a higher level of accountability towards upper management about the success of the project.

In many companies, these people are under constant pressure to deliver. They are usually the ones talking to business departments and they are the ones with end-users breathing down their necks.

So, in an effort to please and please quickly, they will often choose the options that cost the least amount of money and time.

This is not to say that managers have absolutely no understanding of what it means to cut corners now and pay later, or invest now for more benefits later. They know very well how this works. But often, they don’t realize enough how this works on a technical level. Or they might not realize how bad the situation already is. On the other hand, developers usually are very bad in communicating these ideas and principles.

Later Is Never

When confronted with an expensive but good option and a cheap but bad option, it’s often tempting to choose the bad option and tell yourself you’ll fix it later. We’ve all done it in our code. And the same goes for the managers. They tell themselves and the team the same thing.

However, this “later” moment usually never arrives. When “later” is there, there are other priorities, more important things, and it works doesn’t it?

Solution

So how can we avoid these situations? In more or less the same way that we solve it in our daily coding. Don’t fool yourself. Just write the code correctly now, because you probably won’t fix it later. Similarly, when management asks you an estimate of a certain change, don’t propose the bad solution.

Only propose options that you fully support. This could still mean there are several options ranging from good to better to best. But stop offering to do the quick-and-dirty fix that you don’t believe in.

When I ask a carpenter to build me some furniture, a good carpenter won’t offer me some solution that he knows will break apart after one year. In the same way should a good developer not propose solutions that she knows will become a nightmare to maintain later.

Call this craftsmanship, technical excellence, or whatnot. It’s our duty towards our clients and end-users. It’s a fundamental part of being agile in a world that is changing at a very fast pace.

We’re not doing management any favors by constantly implementing ugly quick-fixes. And it’s our job and profession to lead the way, because only we really understand the concepts and consequences of technical debt.

You might even say that all these quick and dirty fixes are part of what gives software and IT a bad name among non-technical people.

Caveats

There are a few caveats however.

A first obvious one is that there are exceptions. As a developer, we should be thinking along with the business side of things, and sometimes circumstances may warrant a quicker and more dirty solution. This is OK. What is not OK is when this is a constant and recurring thing in your project.

Another thing I’ve heard is that certain team members will always propose the quick solution. This indicates a team that is not working as one. One part of the team might only want to propose solution A, while the other part then tells management that they can also do the quicker solution B.

This is due to some lack of maturity and discipline in the team and their members. This is a tricky situation. It can only be solved by educating the team members, by gaining experience. And sometimes, by one of the parties leaving: either the “quick-and-dirty” team members because they’re lacking in the quality they deliver, or the “avoid-technical-debt” members because they’ve had enough.

If your organization, for whatever reason, can’t allow you to write software to the level of quality you want, then you’re not a the right organization. Of course, that may lead to some bleak prospects as you might find that many companies work that way.

But if you can at least pull together a team that refuses to write crappy code, then that’s a start. Because developers are in high demand, you will not get fired immediately. What is probably necessary, is for the team to withstand the pressure for long enough, until management starts to see that they’re having less problems with your application than with others. Numbers and data can help here: bug and issue counts, performance monitoring, etc. These can help you prove to management that your application is actually doing better than others.

Just Stop It

The conclusion is that, with some exceptions, you should stop proposing solutions that you don’t believe in. If you’re alone in your team with this stance, then either your team needs to up their game, or you need to find another team.

Getting your team to improve their quality doesn’t mean you should bully them into it. This requires coaching, patience and a lot of effort.

But if you’re losing faith, a change of scenery might be the best solution for you. Though this also has its downsides. Changing team or company is often a shot in the dark, and it’s not for everyone.