One Best Way - Continuous Improvement in Software Engineering

Table Of Contents

Let’s talk about what it means to find the one best way of doing something. We’ve been trying to answer this question since the dawn of someone teaching anyone how to do a task. Quite simply, it only makes sense to teach the best way you know how to do something if you’re going to teach it at all.

What’s the “One Best Way”?

When we take a step back to consider what goes into declaring the best way, we have to look at what this meant 100 years ago. Indeed, within the last century, this dilemma was being pondered by Frederick Taylor, and Frank and Lillian Gilbreth, among others. With mass production slowly gaining traction, finding a ‘one best way’ wasn’t simply an academic thought experiment but a million-dollar question.

Taylor felt that you should find the most efficient worker in the factory and train everybody else to do things the same way that that worker did. This has become known as “scientific management” or “Taylorism”.

The Gilbreths thought that maybe there was a little more to it and that maybe there wasn’t just a single one best way.

Frank and especially Lillian Gilbreth were also doing some studies that sound modern to us about worker satisfaction, psychological fitness for jobs, feedback loops and fatigue reduction.

These discussions were happening in parallel to Taylor’s experiments in different silos within Ford Motor Company, essentially reinventing the wheel that scientific management was still building.

The emphasis of the conversation was very much on manufacturing physical goods as quickly as efficiently and efficiently as possible. While today’s ‘One Best Way’ discussion centres more on the production of digital goods and services, one salient point stands: if you’re going to teach someone to do a task, you’re going to set the standards for what’s good enough, and you’re going to push for the best way to be the cheapest way to make a buck. None of this is inherently wrong. The pursuit of maximizing our output levels is a natural byproduct of industry. It’s just how business works.

The one best way should be least expensive not only in terms of money but in terms of time, effort, fatigue and materials. In essence, you should be saving on all of that wherever it’s possible. So, the one best way is cheaper, and it’s teachable. We have to have a working cohort that shares enough of the base understanding to produce a predictable product.

Adopting the One Best Way

It’s really difficult to teach a very heterogeneous group of people to do something consistently and reliably. It’s one thing to say that ‘all of our developers follow this code style’, but if you tried to make people in marketing or sales complete all of their work using JIRA with tickets and Git commits, productivity would plummet. It’s vital to have some level of uniformity underlying the work that you’re doing, but not to the overarching detriment of your team.

One way that we get people to adopt this uniformity is to punish failure. This phenomenon is partially why parking fines have proven to be an overwhelmingly successful method of deterring long stays in loading bays. But a better way is to make failure harder than success.

Poka-Yoke (“mistake-proofing”) - it’s not just a great sounding word, but a part of the Toyota method to prevent incorrect operation by the user.

As an example, to start your car, your foot has to be pressing down on the brake. It’s not a technical requirement to start the engine, but it’s a safety interlock. If your foot isn’t on the brake, then maybe the car shouldn’t start, maybe the dog has climbed across the dashboard, or maybe you’re not paying attention to what you’re doing. So, cars make it hard to do the wrong thing by saying “your foot must be on the brake, and then you can start the car”. When we’re thinking about how to do things the one best way, it’s really useful to think about not doing things the worst way and disincentivizing doing things the wrong way.

Continuous Improvement in Agile Workflows

Making failure hard in Agile workflows can be highly effective in building team-wide habits. Error-proofing is also incredibly important when it comes to building resilient continuous improvement (CI) practices. Once you embrace the principle at the heart of Poka-Yoke that mistakes are inevitable, but errors can be eliminated, then you can take an honest look at the way your processes are built to construct the bespoke ‘one best way’ for any given process. Here’s a blueprint that you can leverage within your teams to strengthen agile workflows the Poka-Yoke way:

Create a Committee

To fully capture the impact of current processes around error handling, your implementation team needs to be composed of cross-functional members. You’ll need engineering, QA, product and design as a minimum in order to accurately report on the ‘blast radius’ at hand. It can be tempting to operate with space between our silos but space is dangerous; space is the act of not learning, and the world is not holding still for that.

You probably remember buying computers from companies that no longer make computers, not because we didn’t have the technological know-how, but because they stopped innovating. They built space between their processes, and over time, the reciprocation of feedback came too late in the game.

Provide Proper Context

We need to solicit honest feedback and create a blame-free environment. Encourage everyone to bring their learnings to every discussion and make the review process a safe space for everyone to discuss the performance at its worst.

One of the things that I find in parenting is the limitations that positive reinforcement can pose. Say for example, I want you to wash your hands, and I go check and see if the towel is wet after you’ve washed your hands and see if you’ve dried it off. Well, maybe you wash your hands, and maybe you just got the towel wet. I’m incentivizing the wrong thing because I’m not really testing what I care about. It’s really important to have measurements so that you can get this feedback, but it’s also really important to be aware that your observation of the system changes the system.

Specify Your Metrics

The act of observing can flip a beam to a particle and make people use their metrics the way you want to see. I think we’ve all experienced this at work where somebody’s like ‘well, I get graded on the number of articles I write, so I’m just going to write a bunch of low-quality articles’. I don’t really care if they even get published; you just measured me on how much I’m writing.

So when we’re thinking about how to make continuous improvement, it’s really important that we measure something that shows what we care about, and I really feel like the Accelerate book and the DORA report is a great way to look at things that you can measure that are useful proxies for what you want to be doing is expensive. We resist change because it’s expensive.

Implementation Through Validation

Change is something that we automatically resist because we know how to do the old way, and we don’t know how to do the new one, and that’s pretty terrifying for us. So what do we do? First, we measure what matters. You know this problem; whatever you measure becomes the goal. Monitor for improvements in productivity, reduction in issues and overall adoption. Make it easy for your team to determine whether the change was effective.

Remain Indefinitely Iterative

Remember to ask yourself, ‘where’s the feedback loop?’ in your proposed solution. If we operate with a waterfall method and information only flows one way, it can’t really come back to improve anything. The waterfall is about top-down, being taught, and the one best way. But if we improve the feedback loop. We get continuous improvement. We get a fountain that can power itself at least for a while, and the more rich and useful our feedback loop is, the faster we can improve, the more continuous our improvement is.

Keep Changing

The one best way isn’t any particular way, but rather it’s the act of learning and doing. Continual improvement is something that is really hard to do because, quite simply, change is hard. The only way to be right, to make continuous improvement, is to keep changing. Keep changing mindfully and in view of the feedback that you’re getting, but keep changing all the time.

Catch my talk on the One Best Way from this year’s Spring One conference right here.

Written By:

Heidi Waterhouse

Written By:

Heidi Waterhouse

Heidi is a Principal Developer Advocate. She is working in the intersection of risk, usability, and happy deployments. Her passions include documentation, clear concepts, and skirts with pockets.

Recent Posts

Creating and Publishing an NPM Package with Automated Versioning and Deployment

In this step-by-step guide, we’ll create, publish, and manage an NPM package using TypeScript for better code readability and scalability. We’ll write test cases with Jest and automate our NPM package versioning and publishing process using Changesets and GitHub Actions.

Read more

Offloading File Transfers with Amazon S3 Presigned URLs in Spring Boot

When building web applications that involve file uploads or downloads, a common approach is to have the files pass through an application server.

Read more

One Stop Guide to Java Functional Interfaces

Introduction to Functional Programming Functional programming is a paradigm that focuses on the use of functions to create clear and concise code.

Read more