Seven Habits To Create Reliable Software - Continuous Improvement

This is the last part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider audience.

"Survival is optional. No one has to change.”

W. Edwards Deming

Continuous Improvement

After the Second World War Japan’s industry was devastated. The country was occupied by the United States until 1952. After the occupation ended, the US retained heavy presence and one of the reasons was that it needed to counter any Soviet Union desires for expansion into the far east (remember that the Korean War was in full swing). The US were also worried that if Japan’s population remained poor and jobless for too long it might naturally turn to communism.

In 1947, as a statistician, Dr Deming was asked to help with Japan’s census. In 1950 he was invited to speak to the Japanese Union of Scientists and Engineers and so began his long relation with the Japanese industry leaders. He is credited by many as the man responsible for Japanese post WWII economic miracle.

Perhaps ironically he was more known and respected in Japan than in his home country. This began to change slowly, not much before NBC aired the documentary ‘If Japan Can Why Can't We’ in 1980. In his book ‘Out of the Crisis’, he outlined 14 key principles to transform any business. Principle #5 reads:

“Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.”

You might think that Dr Deming was influenced by his stay in Japan and the self improvement philosophy in Buddhism. However this was not the case as noted in ‘Thinking About Quality: Progress, Wisdom, and the Deming Philosophy’. While Buddhism deals with the self improvement, Dr Deming was talking about improving the system as a whole (and thus ourselves). Before Dr Deming, continuous improvement was not practiced at large scale in factories and enterprises in Japan or anywhere else.

Self Improvement

You need to start with the system that you have the most control on. This is ourselves. Constantly improving, especially in our line of work (software development), is mandatory. Technology changes all the time, customers demand more, there is urgent need to deliver better, faster and cheaper software. It all means that you need to be fluent with the latest tools and techniques. Read blogs, follow influencers on Twitter, attend conferences, read books. Constantly evolve and embrace lifetime learning. This is also good job security advice.

System Improvement

System improvement means to improve the environment where you work and operate. The system also encompasses your customers and your suppliers. For example, when you notice an error — fix it immediately. Need to add a line in a method, but you notice a refactoring opportunity — do it (remember the old boy scout rule to leave the camp cleaner than you have found it). You can improve everything, indefinitely. This is one way to ensure job satisfaction and not to get bored if you stay on a job for more than three years (which seems aged in the software development industry).

The New View

The old Tayloristic approach to management was that the workers just need to do what they are told by their superiors and shut up. Managers do all the planning and thinking for the workers. Dr Deming teaches us that the workers are best suited to notice the problems and suggest solutions. So if you’re in a leadership role, go to the gemba. On a regular basis gather the team and ask each one of them to make one suggestion how a piece of the system can be improved (think kaizen, quality circles). I’d even go as far to say that if you’re having retrospective meetings this should be the most important part — list small improvement suggestions and act on them. Many small improvement amass over time to bring bing benefits. There is no silver bullet, no insta-fix-two-days-solution that most of the managers crave for.

Here are some actual examples of things that are important to engineers to be improved:

  • The build is taking 10 minutes, can we make it less than 5?
  • Setting up development environment on new employee’s PC is done by hand every time. Can this be automated?
  • Data for testing in staging environment comes as a subset from production data, but is manually scrubbed for PII by the operations team. Can this be scripted?
  • Each night, at 4am, an email with an error from production is being send. It’s not a bug actually, but can we fix the problem to stop the emails that are piling up in everyone’s mailbox.
  • We have to fill out an online time sheet each month, what projects we’ve worked on and it takes 15 minutes every week per person. Can this information be taken from the tasks assigned to me in Jira automatically?

When you do some improvement, show and teach others in the company what you’ve done and how they can do the same. This way your company is rapidly learning and the feedback process is constantly being amplified. This is described in details in The High-Velocity Edge book.


Company leadership needs to realize these are activities that will not result in any immediate revenue. However they will pay benefits in the long run. In the book 'Drive: The Surprising Truth About What Motivates Us', Daniel Pink writes that there are three main drivers to keep us engaged in the long run in whatever we do. Autonomy, mastery and purpose. Continuos improvement is the second one — allow your employees to constantly pursue higher mastery of their craft. They will not get bored and leave as they will see the results of their work and their improvements implemented. If will also keep your company in business in the long run. Don’t believe me? Just start reading W. Edwards Deming, probably the only books on management you’ll ever need.

The rest of the related posts can be found here: