Consistency

This is the first instalment in a series of articles about six core principles that my team, a software development team, and I compiled in order to develop a framework for decision making. The reason for building the framework was to build a common understanding of how we want to work. Writing it down allowed us to easily transfer that knowledge to new colleagues and to spread the word.

In this article I discuss what I think is one of the most important and fundamental requirements not only for software development, but for successful management in general: consistency.

“Consistency is the building block of trust.” Foto credit: Marina Smyres.

Summary

Inconsistency and the resulting uncertainty lead to anxiety, stress and ultimately to errors and failures. Stopping this downward spiral requires different countermeasures. Best practices and unit tests help increase process and product quality and thus reduce development costs. Automation simplifies tedious and error-prone procedures and makes them repeatable. Establishing a continuous improvement process that involves the team as a whole will foster trust and hence stability. Increasing efficiency along with effectiveness will enable your team to do the right things right.

The Situation

Inconsistency arises when similar or equal issues and situations are addressed differently. In software development this happens when different engineers solve the same problems by implementing slightly different algorithms every time. Instead of extracting common solutions into reusable items, they reinvent the wheel as they seem fit. The consequence is that, every implementation has it’s unique set of bugs. Fixing a particular bug may require changing every occurrence of similar but not equal implementations. This makes working on software both unnecessarily time consuming and frustrating. Not having common patterns and toolset may lead to uncontrollable chaos. Imagine a software engineering team where every member develops software components with his own preferred programming language. What about every team member developing his own ORM layer? What if a colleague leaves? Who is going maintain her work?

Challenges

Anxiety

Inconsistencies ensue when different people come up different solutions to solve the same problem. Sometimes and in extreme cases this is called reinventing the wheel. While I’m a big fan of TMTOWTDI this approach may come with a drawback. Every particular solution has its own peculiarities, its own distinctive bugs and will behave differently in corner cases. Fixing a particular bug in such an environment may require changing every particular solution of a given problem. Each time addressing their particular oddities. This makes work unnecessarily time consuming and frustrating.

Not being able to estimate the cost of fixing a bug leads to anxiety: “What rabbit hole will I enter this time? Will I underestimate the workload again?” The absence of unit tests my make this even worse. Without unit tests engineers has no means of verifying that a change doesn’t have unexpected side effects. It’s not without reason that some people say that “code without tests is bad code”.

Stress

An environment where people don’t know what to expect because everything is differently every time, ultimately leads to stress. Confronted with this uncertainty people are always fearful and busy thinking what might come next. Stress causes the release of cortisol, a hormone that suppresses the immune system. Over a longer period of time this makes people sick. Watch Simon Sinek, author of Leaders Eat Last, explaining the odds of cortisol: Simon Sinek: Why Leaders Eat Last.

Errors and Failures

Anxiety and stress, among the other problems mentioned, culminate in failures. They often come with the pressure to deliver fast. It is a disastrous combination that leads to errors. Quality assuring measures like unit tests or code reviews are usually the first casualties when development gets under pressure of time. This is not long before failures start to happen and the downward spiral of anxiety, stress and failures starts to spin. Failures are among the most impactful factors that cause higher development costs.

Higher Development Costs

Inconsistencies often require workarounds. Workarounds in turn lead to more workarounds. This condition has been discussed by Ron Jeffries in an article titled “Refactoring — Not on the backlog!”. Higher developments costs do not only disappoint customers and stakeholders. That disappointment swings back to developers, because what they really want is to do a good job and make customers happy.

Solution

Best Practices

Well known, well documented and taught best practices help people adopt common problem solving strategies. Extracting common algorithms into libraries makes them reusable. This in turn facilitates broader adoption. Broadly used software is broadly tested software and if it’s used, it get’s worked on, debugged and improved.

Unit Tests

Michael Feathers writes in his book Working Effectively with Legacy Code:

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

– Michael Feathers, Working Effectively with Legacy Code

Write unit tests! The costs for writing them is far lower than those which follow if you don’t write them.

Automation

Automation increases efficiency by letting machines to repetitive work. It brings reproducibility and can make your development process easier by simplifying long and tedious procedures. Furthermore it allows a development team to deploy early and often.

Continuous Improvement

Do you regularly take time to sit back and think of ways to improve what you do and how you do it? – You should! Stephen R. Covey calls this “Sharpen the Saw” and it’s one of his The 7 Habits of Highly Effective People. Jeff Atwood of Coding Horror has devoted an entire article to it: Sharpening the Saw.

Sharpening the saw on an organisational level is about having a continuous improvement process. There are different ways to implement it. Personally I’m a big fan of Kanban, a method for process management and improvement inspired by the Toyota Production System. In the end it’s about regularly taking some time off, looking back and analyzing, drawing conclusions and learning, implementing measures and iterating. Continuously implement small improvements that stick by involving the team into the whole process.

Results

Trust and Stability

Achieving consistency in your development process and throughout all aspects of your organisation will foster trust. Clear priorities and expectations that are well communicated and documented reduce unnecessary friction and help people focus on important things, thus improving organisational stability. Special care has to be given in order to achieve the required level of concise communication, it is a challenge. An environment of trust will make your colleagues feel comfortable and will attract the employees you want.

Efficiency

Reducing unnecessary friction and focusing on well defined goals with clear priorities greatly improves efficiency. It is the managers responsibility to set clear goals and at the same time it’s the team’s responsibility to challenge them and point out ambiguities and inconsistencies. Finding the sweet spot is teamwork. Efficiency is a process that needs constant care in the form of a continuous improvement process.

He who stops being better stops being good.

– Oliver Cromwell

Effectiveness

It’s important to do the right things right. Doing the right things wrong is futile. By doing them right your team will avoid having to clean up waste like muda, muri or mura. This in turn gives your team more time and freedom to carefully choose the next steps with minimum legacy and liabilities.

Conclusion

Consistency is a fundamental characteristic of successful organisations. Not being consistent causes a vicious cycle that makes the organisation unprofitable and unattractive. The steps to achieve consistency are fairly simple but require endurance and stamina. Adopting them to your needs and involving the team in the process is key.

I’d love to hear your experiences and opinions.

Thank you Nils Caspar for writing the initial version of this article.

From Dev-Team with ❤