I once worked at a client site where the technical lead told me not to waste time writing tests. Speed was important and writing tests was a waste of time. Besides the fact that that's a fallacy (I write code better and faster when I include tests), it also implied I needed his permission to write tests. And it wasn't a good time for writing tests. We had to proceed fast.

When your developers are asking for permission to write unit tests, you have quite a problem.

Let's say you contract a construction company to build you a house. How would you react if they asked you if they can use a certain technique for the foundation? I for one would probably blink and say I really don't care as long as it's a sound technique that will give me a quality result. I might ask if it's more costly or takes more time to dry compared to other techniques. But given all things more or less equal, I really wouldn't care. It makes no sense in them asking me. Indeed, I'd be slightly alarmed if they did. Do they not know their craft well enough? And if the cost is more or less the same but leads to better results (like I believe unit tests do), then why would they even ask? 

Lack of Skill

This brings me to a first problem you might be having. Do your developers lack the skill to get started with unit testing? Unit testing is not a new buzzword in software development. It's an industry-wide best practice, and you should be wondering why they weren't already doing it. But skills vary, so we can forgive them for not knowing how. The good thing here is that they seem to want to write tests. Your problem now lies in the fact that they don't know where to get started. The solution here is fairly simple: let them follow a course on unit testing and/or bring in a coach to teach them.

The problem of your developers not being familiar with writing test might take some time to fix, because they have to learn, but it has a fairly straightforward solution. You have a bigger problem if it's a culture problem.

The Culture Problem

There can be various underlying cultural issues at play here. I'll cover the following problems that your organization might be having:

• Do developers not have freedom to make technical decisions?
• Is there a blame culture in the organization?
• Is there too much pressure on developers to deliver features?

Permissions for Everything

Is it normal procedure for developers to ask permission for technical decisions? Or worse, do they need to ask permission for everything? Do other people see them as mere cogs in a machine? Hardly anyone will answer yes to those questions, but many companies show great skill in fooling themselves in this regard.

If developers get the feeling that they need to ask permission for the smallest things, it will discourage them greatly. Morale will quickly reach an all-time low, because they feel the organization doesn't trust them, their experience, and their knowledge. Worse, it will prevent them from learning and becoming better developers. This will lead to what we call the Dead Sea effect.

The Dead Sea effect happens when an organization's culture makes smart people go elsewhere, leaving only the less talented. The skilled people get frustrated with the culture and know they can easily find better places to work. The less skilled colleagues have a harder time getting into other companies, so they stay. In the end, the organization is left with less capable people.

All of this (having to ask and wait for permission, reduced morale, skilled people leaving) slows down development time and time to market. Such an organization can never claim to be "agile", regardless of its internal processes. So even if they "do scrum", it will be a slow-moving company that has a hard time reacting to changing market conditions. This will have a negative effect on the bottom line.

Blame Culture

Do you have a blame culture and do they want approval so they can point to someone else when things go south?

I remember a client where we, a new team, asked another team if we could introduce a certain practice in the code. The answer we got was that they would have to ask someone with more seniority. It wasn't something they could decide themselves. To us, coming from a different background, this was ridiculous. Not only because we had to wait until that person was back from vacation. But also because we were used to taking team decisions. And team decisions meant team responsibility. In the other team, people didn't make decisions out of fear of possible repercussions later.

This is crippling for an organization. Innovation stops and people no longer try to solve problems themselves. They will quickly pull their hands off a problem and look up the hierarchy for some decision. If this becomes rampant, the people higher up will look even higher until some C-level manager is reached. Everything comes to a screeching halt and things seem like they will never change.

This too will lead to the previously mentioned Dead Sea effect.

Features, Features, Features!

Is there too much pressure on the team to crank out feature after feature? Does the business constantly tell the team there is no time for follies? That they needed this feature yesterday?

If this leads to developers cutting corners and not writing tests, you have two cultural problems. The business people should allow developers to write their code in a modern and professional way. If they don't, they're jeopardizing the business in the long run. When the applications become such a big mess that each new feature takes longer and longer to develop, and each new deployment comes with an increasing number of bugs, it will be because of the continuous pressure put on the developers.

On the other hand, it's also up to developers to refuse to work this way. A professional developer will tell the business that quality code and tests are the standard way of developing software. If they don't, your developers lack either professionalism or experience. The latter case can happen with junior developers and shouldn't be an issue in a team that has more experienced and professional developers. But if you lack that too, this irrational focus on cranking out features fast will come back to bite you.

Developers will become frustrated because there is no room for quality. Fatigue will kick in because they are constantly fighting fires and trying hard to keep up the pace of development. This too will lead to the Dead Sea effect. And it will leave you with a pile of code not many people will be happy to work in.

None of the Above?

Maybe none of the above reasons apply, but the developers are still asking permission to write tests. If that's the case, then you should get together and talk to the teams. Get to know them and learn their motivation for asking permission. Educate them so they can grow into professional developers. Start building a company culture that gives them trust and responsibility—a culture where they don't feel they need to ask for such approvals.

How to Turn It Around

Back to my story. What did I answer when I was told not to write unit tests? I politely told him it's the way I work and I would be writing tests anyway.

Developers should write tests as a standard way of working. This is generally agreed upon in the professional software development industry.

Managers should talk to the developers and encourage them to write tests. If there isn't enough experience yet, they should provide courses and/or coaches. I've given sessions on unit testing in the past and in most cases developers were very interested, even if they had zero experience with testing.

Once developers know how to test, management should create a culture where taking initiative and experimenting is encouraged. In such a culture, people will feel trusted, know they won't be blamed when a mistake is made, and perform better than they had imagined. Your project and bottom line will benefit.

This post was written by Peter Morlion. Peter is a passionate programmer that helps people and companies improve the quality of their code, especially in legacy codebases. He firmly believes that industry best practices are invaluable when working towards this goal, and his specialties include TDD, DI, and SOLID principles.