Day Zero Software Delivery Best Practices

Changing Software Quality Accountability

I've spent most of my professional career as a software quality advocate. During that time, the definition of software quality and the people who are responsible for it has changed drastically. The idea of disparate development and test roles is becoming less and less common. Rather, software engineers are now expected to have a breadth of software delivery experience which includes not only software development, but also operations, test, infrastructure, build and release engineering. This shift in software organizations' cultural norms has given way to faster delivery, higher quality, greater accountability, better communication, less blame and increased trust.

Observations of High-Functioning Software Delivery Teams

Over the past several years and multiple consulting engagements, I began to evaluate a organization’s capability to delivery quality software based upon its processes, organizational structure, culture and technical best practices. I observed that the highest-functioning teams gravitated toward lightweight processes (mostly lean and/or agile), cross-functional organizational structure and accountable-yet-blameless culture. These teams employed technical best practices such as test-driven development, pair programming and a mix of continuous integration (building and testing every change), continuous delivery (keeping the top of tree in a constantly shippable state) and continuous deployment (shipping each new change to production as it is introduced). These teams selected engineering tools, not because they were sexy, shiny or fashionable, but because the tools helped to increase the team's efficacy and underlying business value.

Considering that software quality accountability throughout the engineering organization has become an accepted industry standard along with the identification of fairly well-understood characteristics of high-functioning teams, it might seem that the challenges of high-quality software delivery will soon be a thing of the past, right? Let's hope so! Realistically speaking, it's probably not going to happen all too soon.

Software delivery optimization is not too difficult to understand, nor is it hard to convince the engineering team or business stakeholders that it’s valuable. What makes good software delivery difficult is history. Most teams are not fortunate enough to build software delivery best practices in from the start. Legacy code, archaic processes and toxic organizational behavior are key impediments to impacting meaningful change in brownfield software environments.

Day Zero Software Delivery Best Practices at Oomf

When we started Oomf, we had a unique opportunity to employ what I call "day zero software delivery best practices." Before a line of code was written, we made a conscious decision to focus on building high-quality software by focusing on hiring talented engineers based upon their breadth of expertise while simultaneously obsessing over characteristics of high-functioning software delivery teams. As a result, we’ve built a disruptive software business with a very small, but incredibly effective, group of engineers and business people.

Validation from Tech Icon and Software Delivery Pioneer

Yesterday, the Oomf engineering team had the pleasure of hosting Jenkins creator and CloudBees CTO, Kohsuke Kawaguchi. Kohsuke has made a significant effort recently to connect with Jenkins practitioners outside of the Bay Area in order to better understand their software delivery techniques and pain points. When I found out that Kohsuke was headed to Boston, I jumped at the opportunity to show him how we deliver software at Oomf. If anyone could validate that our implementation of day zero software delivery best practices was worthwhile, it would be Kohsuke – he’s kind of a big deal.

The feedback from Kohsuke’s visit was both gratifying and flattering. While I wasn’t able to attend due to travel, the team reported that Kohsuke seemed "impressed with how sophisticated our software delivery practices are given the small size of the team.” They added that Kohsuke “thought it was very interesting that we invested as much as we have to build software delivery best practices into our company culture from the beginning.” 

Thanks, Kohsuke!

As it turns out, the Oomf engineering team is comprised of fierce Jenkins loyalists – myself included – who have been promoting and proliferating Jenkins across a multitude of companies, organizations, and teams since the Hudson days.  Jenkins is a tool that has enabled our implementation of day zero software best practices as it has consistently allowed us to increase our team efficacy and resulting business value.

Proliferating Day Zero Software Delivery Best Practices

Successful implementations of day zero software delivery best practices are fairly rare considering that they must be in place before product and organizational history is established. Young software startups can and should capitalize on their lack of significant history and institute these best practices early on.

As part of Oomf's commitment to the MassChallenge community, we look forward to sharing our engineering experiences with other finalists. We believe that proliferation of software delivery best practices leads to the highest quality products, the best corporate cultures, and a better software industry overall. We're excited to meet our cohort colleagues at the MassChallenge startup showcase on June 28 to begin the conversation.