Leave Nothing to Chance

“We learn from failure, not from success!”
– Abraham Van Helsing, Dracula

Last week, I gave a presentation called “Leave Nothing to Chance” at the Nebraska.Code() conference. The essence of the talk was the value of locking down all the little decisions to better ensure success in your software projects.

I started the talk with an overview of a few of the failures we at Don’t Panic Labs have experienced as an organization. I tried to tie those failures in with the changes we made to prevent them from occurring again. A good example was us jumping on a cloud platform in 2012 before that platform was ready for prime time.

I talked first about the importance of ensuring that your team achieves a shared understanding. You won’t have a successful project if you don’t have everyone on the same page. Many tools can be used to get a shared understanding. Some of the tools can be as basic as creating a backlog. This lack of having the same understanding can have huge negative impacts on a project. Rework is extremely expensive. Rebuilding a lot of code because there wasn’t the same understanding is frustrating, time-consuming, and costly.

The next area covered was user experience validation. Anything we can do to ensure that the user interface closely represents what customers expect will lead to a huge reduction in rework. Validation of user experience helps to suss out not only the user experience design but also the very requirements of the project. I don’t know how often I have experienced UI designs that uncovered missing or invalid requirements.

The third area is ensuring that we write software that ages well and is software we will be happy to work on for years to come. This is one of the pillars of funability, a term Doug Durham and I coined a few years ago to describe software projects that are enjoyable to work on.

The fourth topic was setting up our systems, processes, and environments to ensure that developers naturally fall into the pit of success. We want to make it as easy as possible for developers to do the right thing. It should be easier to write a good unit test and verify your code works than it is to skip that step and do manual testing first.

The fifth topic was the importance of technical leadership. Without good leadership, we might end up using software on platforms with huge issues. During my talk, I gave an example of one Sunday when I moved a project from one platform to another. I did this work on a Sunday was because the cloud provider was having big issues that negatively affected us. But it was poor technical leadership that allowed us to make that decision and put us on a bad platform in the first place. But technical leadership isn’t just about platform selection; it is also about focusing on the technical quality of our solutions. Some of that focus will be on a platform selection, but some will be on helping to coach up other developers.

Much of what is discussed here is covered in much greater detail in the book Lean Software Systems Engineering for Developers, which I co-authored with Doug Durham. As a takeaway from this talk, I would encourage people to think deeply about many of these topics and try to find ways to minimize the chance of something going wrong.