I Don't Wanna

thoughts on building quality software in the 21st century

There was a time in software development when specialization was necessary. In How We Test Software at Microsoft, we told the story of the first tester at Microsoft - who was hired to run games written in Basic through the new compiler. At that point a divide between test and development was forged (lightly at first).

Years later, The Unicorn Project by Gene Kim (and more directly, his DevOps Handbook) talks about the similar divide between developers and operations specialists and shows how breaking down those walls accelerates and improves software delivery.

The Wall

I’m not alone in my hatred of using the term DevOps to describe a role within an organization. DevOps isn’t a thing people do, it’s a way people work. It started as a term to describe the cooperation of Developers and Operations team - famously discussed in this 2009 presentation - 10+ Deploys Per Day - Dev and Ops Cooperation at Flickr.

The concept is simple - cooperation and collaboration are incredibly more efficient than chucking stuff over the wall to another team.

Those of you who have worked in test roles may see the parallel. That first tester at Microsoft grew into armies of testers. In the mid-2000s, there were nearly 10,000 testers at Microsoft, and while they were involved early in the product cycle and cooperated (to varying extents) with development teams, there was a lot of over the wall chucking happening across the company.

These days, most mature organizations realize that hand-offs slow down velocity and introduce risk. To this end, many companies have realized that they need far fewer testers than they once did. Developer owned testing (often assisted by testing “experts”) is proven to be highly correlated with quality and delivery.

Similarly, the rise of the DevOps culture has produced central “platform engineering”, or “developer experience” teams that build a foundation of tools and automation - along with expertise when needed, to make it easier for development teams to run cloud-based services and applications.

As early as 2006, Werner Vogels was touting the You Build It, You Run It culture.

Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

There are a lot of things I don’t like about Amazon - this is not one of them - and this is also exactly why I believe (and have seen) that developers owning the vast majority of testing also leads to better delivery.

The Whiner

The data on this are out there. Good software teams optimize for efficiency and quality by reducing hand-offs and owning delivery of their product. But (and as I’ve seen in comments when I’ve made similar statements) there are developers who don’t give a shit about the data, because they “don’t want to do testing”, and they “don’t want to do DevOps”.

Those people are dumb have a fixed mindset.

In Mindset, Carol Dweck talks about this. She says that that people's approach to learning and challenges is framed by either a fixed or growth mindset. People with a fixed mindset see their abilities (or what they do) as fixed and innate. These folks avoid challenges and feel threatened by failure. On the other hand, folks with the growth mindset embraces challenges and new ideas as opportunities to learn.

If the data say that developers owning more testing and operations aspect of their software is beneficial - and your response is “not my job” - your growth is limited - and so (IME) is your career.

The Worker (and the learner)

I’ve interviewed a lot of people for tech jobs in my career. The super-secret (yet not-so-secret) trick I’ve used to find candidates that will succeed in the long-term is to focus on learning and mindset. If you want to be successful in tech - or in any knowledge work, a love of learning, and a fearlessness to take on new challenges is (IME) is highly correlated with lasting success. The inverse is also (again, IME) true.

For years, I helped organizations learn to function with fewer testers. Because history repeats itself in new ways, I’ve also helped development teams learn to run what they build (or as Bryan Finster puts it - “run what you brung”). I’ve had consistent success in doing this, but not without fear and conflict.

Sometimes, a developer doesn’t want to learn how to test or about service delivery because they think that they’re above it and it’s “someone else’s job”. They disbelieve the data and refuse to change. At first. Starting with small changes (e.g. unit tests or integration tests), or pairing on a deployment is a start. Continue with gradual change, and the results will be clear.

Most often, the reason for don’t-wanna-syndrome (and where the “someone else’s job” folks inevitably show up) is fear. Developers are afraid (at first) of testing, because they are afraid they may miss a bug (meanwhile, testers got over that fear decades ago). Developers are afraid to run their own stuff because they’re afraid they’re going to somehow blow away the entire internet or cause some other irreparable damage.

Mostly, they’re afraid of trying something new.

When testing and deployment are handled “magically” by some other team, a lot of developers assume that it’s just a lot more difficult than it actually is (cue the testers telling me that I just belittled testing). What I’ve found numerous times is that a little pairing and a little knowledge transfer grows quickly into a lot of curiosity, a lot of growth, and a whole lot of quality improvements. I have seen developers become better at testing than 95% of the testers I’ve known in my career, and I’ve seen developers discover details and nuance in Kubernetes that I’ve made them teach to my platform teams.

Somebody on Linked in mocked me for saying this, but I’ve found that simply giving developers permission to test and run their stuff goes a long way towards growth and maturity.

The Winning

I’m not advocating for every company to eliminate their testers or platform engineering groups. Expertise is good - but be wary as it can also be a bottleneck. You don’t want development teams to be dependent on another team - instead test teams and platform teams and dev experience teams should accelerate the ability of those teams to ship high-quality software.

Your test team exists to help teams test better - not to do the testing for them.

Your platform team exists to help teams run their services better - not to run their services for them.

Learn, grow, and make better software.

-A 0:0