soupThe other day my daughter wanted to heat up some soup in the microwave. She insisted on doing it herself. The lid of the Campbell’s Soup can the type with a tab that can be opened without a can opener. She stood in front of her mother as she attempted to open the can, wrestling with it a little. “Lift the tap up, and then pull on it,” her mother instructed. She added, “I really think you should open it in the kitchen over the sink.”

My daughter struggled with the lid, but still didn’t want help–she wanted to prove to us and to herself that she was capable. Soon enough Campbell’s Double Noodles were spilled all over the floor and her mother. Oops.

Did we get mad? No way! How could we? We knew the possible outcomes, but we also knew that we had to allow our daughter to figure this out. My daughter learned a few things in this situation:

  1. How to open a can of soup.
  2. What can go wrong if you tip the can sideways while opening.
  3. Why she should have done it over the sink.

Now, if my daughter comes home from school today and does the exact same thing, spilling soup on the floor, I think I’ll be frustrated. I’ll probably say something like, “Didn’t you learn from what happened before?” In the situation described above, I helped my daughter clean up the mess, and even though she felt bad, I told her not to. “This was a mistake,” I said, “and next time you’ll know how to do it the right way.”

I shared this article on LinkedIn a while back. From Forbes: Good Employees Make Mistakes. Greater Leaders Allow Them To.

From the article:

We all make mistakes. Every one of us. If we aren’t making mistakes, then we likely aren’t trying enough new things outside our comfort zone, and that itself is a mistake. That process is the best way to learn and grow as a person.  As John Wooden once said, “If you’re not making mistakes, then you’re not doing anything.” Mistakes are the pathway to great ideas and innovation. Mistakes are the stepping stones to moving outside the comfort zone to the growing zone where new discoveries are made and great lessons are learned. Mistakes are not failures, they are simply the process of eliminating ways that won’t work in order to come closer to the ways that will.

The advice is generally pretty good, although I don’t necessarily agree that making the same mistake a second time is as critical as the author suggests (hence the term: mistake). Particularly in software, a large project can include complexities of such significance that mistakes can and will happen. This is all part of it. We shouldn’t be overly relaxed about software mistakes, but even the best software engineers have missteps. It is wise to learn from mistakes and prevent repetition in the future, but sometimes, despite our best effort, mistakes happen.

The suggestions on how to follow up from a mistake are great:

  1. Learn from them.
  2. Own them.
  3. Fix them.
  4. Put safeguards in place to ensure the same mistake will never be repeated again.

Owning a mistakes isn’t easy. It is very tempting to make excuses, especially when a project is extremely complex with multiple contributors. For example, if software I wrote fails because of an interface change, who is at fault? Is it me, because my software didn’t properly adapt to a changing interface, or is it the interface designer, because I wasn’t told of the interface change? That’s not an easy question to answer, and ultimately it doesn’t matter all that much. We’re all on the same team. In a case such as this, owning the mistake means taking on the responsibility to correct the mistake, whoever is at fault. If management is in touch with what is going on, it will be known that there are many moving parts, and the individual who takes ownership, hopefully, will be respected and appreciated.

As far as the role of leadership goes in all this, a great leader is most certainly one who has faith in his or her employees, and one who allows employees to branch out. In Becoming a Person of Influence, John C. Maxwell states that a good leader must nurture:

As the people you nurture gain strength, give them additional opportunities to succeed and grow. You will continue to nurture them, but as time goes by, their actions and accomplishments will help them remain secure, respected, and encouraged.

He also states:

People rise or fall to meet the expectations of those closest to them. Give people your trust and hope, and they will do everything they can from letting you down.

These statements are broad, but relevant here. In my experience, branching out necessitates mistake making, and it also necessitates the type of leadership that recognizes this. I can say in all honesty that I’ve learned much more from mistakes than I have from successes–and I do believe that most of my successes have come after a series of initial mistakes.

From a software perspective, think about how one develops well designed code. Those of us with years of experience in the field are able to think through possible pitfalls in design and create software that is engineered based on many lessons learned. Many times, at least in my case, I think about previous projects I worked on, and I recall things that worked well and, more importantly, things that didn’t work well. Much of writing software involves trying things out, observing what works and what does not work, and continuing forward based on lessons learned. In some ways, the difference between a mistake and an attempt can be subtle. (I’m not talking about software that is released with defects in this case.) Admittedly, these points are a little more philosophical.

I don’t mean to suggest that writing software is simply an exercise in mistake making–and I especially don’t want to suggest that we should expect defects in a released product. I do suggest that software development can be very hard, and mistakes will happen. This is why we have dedicated software testers. It’s also why test driven development has gained such a strong following.

Back to the list:

  1. Learn from them: Make the lessons learned be a lasting part of your engineering background. This is where years of experience becomes an asset.
  2. Own them: Finger pointing doesn’t help a team, and it makes the individual pointing the finger look bad. Don’t bother. Move forward.
  3. Fix them: Naturally.
  4. Put safeguards in place to ensure the same mistake will never be repeated again: In terms of software defects, such safeguards are pretty easy. If the mistake is related to the process, address the process. If it’s a software defect, add to the validation plans and unit tests. Test-Driven-Development cannot prevent all possible issues. As software matures, new scenarios and unexpected edge cases should cause a parallel evolution of tests.

Will the mistake never be repeated? That depends on many things. Ideally, if safeguards are put in place, the answer is no. (Well, to nitpick, the answer is actually yes–but safeguards should catch mistakes before they manifest in damaging ways.) In all honesty, however, mistakes happen, sometimes repeated ones. Good management will make the effort to understand the nature of a mistake, and recognize the true cause. If it is repeated carelessness, then clearly there is a problem beyond simple safeguards. Hopefully this isn’t generally the case. If, rather, the mistake is a result of code complexity, crushing timelines, or poor design, it is the environment and the process that needs to be examined and corrected.

It wasn’t all that long ago that I received an email alert while in a small meeting. “Dang, I broke the CI build,” I said. My boss laughed a little and responded with, “Good, that means you’re getting work done.” He was right. I forgot to commit a fail to a checkin. My personal ‘safeguard’ failed: The build worked locally for me, because all the files were in place. The CI build failed because I didn’t check all of my changes in. The good news is that, while we strive to keep the CI build happy, CI is really just another in a series of safeguards. CI builds break… And I say GOOD! A broken CI shows us where there is an integration failure. In this situation it was minor, but in others, assuming we have proper automated testing, a broken CI can expose much more serious issues (also good).

Thinking about the can of soup that my daughter spilled: There is a reason that I always open soup over the sink. I’ve opened countless cans in my lifetime, but every once in a while, I still slip up and spill a little! This is why I use a safeguard when I open a can (i.e., the sink).