The desire to prevent adversity is a natural instinct.
As humans, as individuals, we generally do what we can to avoid something going wrong. This is especially true when we invest a lot of our time and effort in a project.
Say you spend 40hrs per week on a particular project for a year. The project may become a part of your identity. At the least, you will be personally vested in a positive outcome.
The more time we invest, the greater our fear that something might go wrong. In this way, investing time and resources in a project is almost like raising a kid.
We do everything we can to set our project “children” up to avoid and prevent problems with the intent that they achieve success. Similarly, we do everything possible within reach of our finances and power (and sometimes beyond) from schooling to extracurricular activities, to ensure that our kids have the best chance in life as is possible.
Investing in our kids is a bit like defect prevention in software process improvement. Just as many theories of parenting existing, many methods of defect prevention exist. Some of them, such as Six Sigma look for the root causes of failures with the intention of preventing failures before they occur.
In prevention, we must continually ask why something might break and then fix the underlying causes. On one hand, this is very much like parenting.
A challenge in prevention work is that to be effective, detailed and good requirements are a necessity. For example, if 6 months ago someone rushed the requirements and left out a key step or valuable information, you will likely soon discover a slew of bugs in your project.
This kind of noise easily distracts us from the underlying issue that the problem came from faulty requirements. Either way, your project is delayed. And, if you have to hand over issues with requirements to another department, your work on a feature may suddenly grind to a halt.
At this point, the best you can do is note why the problem happened and resolve to do better next time. Prevention work is not always timely.
Appropriate applications for prevention work…
Prevention work generally means lessons learned for the next iteration. We might learn how to more accurately prepare requirements during implementation. Or we might learn to focus better attention on our code after we’ve already deployed.
In prevention, we learn from problems we encounter so that we can prevent those problems in the future. By paying more attention to difficult steps or stages, we learn what to avoid next time. Effective prevention work, in effect, creates a system that can create successful future projects, and in then it follows a company that can consistently launch successful products.
Shortcomings of Defect Prevention: Defect Prevention and Rare Events
Let’s return to the parenting analogy. Defect prevention, when applied to parenting, shifts our target goal away from our current child so that our end goal becomes setting up a system to be better parents to our future children.
I’ve chosen the parenting analogy because it clearly highlights a shortcoming of the defect prevention method. In real life, humans are highly invested in carrying out tasks that will ensure the success of already existing offspring. Unlike in prevention work, most parents don’t (intentionally) use their first child as a test case, to learn how to be successful with their future offspring.
What’s more, many families may choose only to have a single child or they may space their children 5 or 10 years apart. Defect prevention is a waste of resources if you lack a future (and immediate) application.
Prevention work is not appropriate for rare events.
Lots of small and medium-sized companies are not software companies, but companies that also do software. Software for them is a necessity, but not a business. For these companies, a software project is likely a rare event.
In prevention the entire feedback mechanism is reactive. If you want to use prevention, you will make your next project better with the lessons you learn, not your current project.
As we know, many companies may support only one or two software products and or they may only have a software development project come about every few years. Defect prevention that demonstrates how requirements could have been better 6 months ago may give comfort in the form of an explanation, but they will not solve existing and relevant problems.
Please, have a seat on the couch: explanations vs. solutions
Prevention methods may help you change your perception through the receipt of explanations, but they won’t give you solutions to an active problem. Let’s say the parent of a college student visits a psychologist to discuss problems they encountered raising their now young adult. The discussion and insight help the parent to understand and accept what they may have done right or wrong. But this explanation and acceptance will not fix a problem, it simply will change your perception of a problem. Of course, perception is significant, but it’s not a solution.
The discussion and insight may help the parent to understand and accept what they may have done right or wrong. But this explanation and acceptance will not fix a problem, it simply will change the parent’s perception of the problem. Of course, perception is significant, but it’s not a solution.
Resilience through rapid corrections…
An alternative is to simply pursue resilience through rapid corrections. Think of this like driving. Seated behind the wheel of a moving car you constantly process multiple pieces of information and feedback, adjusting your speed, direction, and so on. Driving requires constant attention and focus.
It’s a given that the closer we pay attention when driving, the better our results. Paying less attention, such as texting while driving, often results in the occasional need for bigger or last minutes corrections. Sometimes the information arrives too late or not at all and the result is an accident.
Attention + Discipline = Positive Results
This method again applies to raising children. Children and custom software development projects both require close attention. In child rearing there is a saying that “discipline is love.” Pay attention to your children, apply the rules consistently and thoughtfully, and generally speaking, they will grow up without too many bugs!
In correction (versus prevention) you pay constant attention to your custom software development projects. This focus allows you to react to problems and correct in a timely manner. Consistent attention and disciplined application of requirements result in a better end product. Rapid correction builds resilience.
Focus on reactive resiliency…
How we change as we go through production is a function of lessons learned, but also our ability to adapt, such as an outage to a new test case. Or perhaps some more automation to email for failures, so that we have the tools to pay closer attention and fine tune our responses as needed.
In correction, we maintain the goal of improving for future projects. We will still change systems and processes to fix defects, but we are less interested in learning how and why our problems exist. Instead, we focus on continually improving our near future. In correction, our immediate goal is to make today better than yesterday. And then tomorrow’s production a little better than today. Your ability to react quickly and appropriately builds resilience.
Instead, we focus on continually improving and resolving for our near future. In correction, our immediate goal is to make today better than yesterday. And then tomorrow’s production a little better than today. The ability to react quickly and appropriately builds resilience.
Deciding on Prevention or Correction
Know your company, know your goals: are you in the business of software development or are you a company that sometimes develops software?
In custom software development we come across different types of companies and goals. Some companies, say a mortgage company or an insurance company require software to function, but their business is not software. If your team is only involved the occasional software project, then it is likely more efficient fro you to focus on resilience trough correction over prevention.
From an industry perspective, it would be awesome if we could benefit from group intelligence and expect continuous improvement on every custom software project. Prevention across teams and companies is an ideal goal. Unfortunately, for the moment lessons learned on unique and rare projects cannot be easily shared. Concrete results or lessons learned are seldom shared across companies by anything other than word of mouth.
For infrequent projects, correction is best …
Until there is a method to consistently record and move beyond oral histories of software projects, the parties involved are most likely better off focusing on correcting problems in the projects we work on rather than preventing problems in future projects.
You can do both, but neither is free and prevention is most effectively applied to future projects. Decision makers must thus be careful to prioritize solutions that are best suited to your particular situation, project, and company.
If you are interested to know more about how we use correction at Possum Labs please feel free to contact me or start a discussion below.