Watching organizations trying to figure out how to improve their software development processes reminds me of the old joke about the drunk looking for their wallet.

‍

I once worked for a senior exec who thought that the key to effectively managing his fast growing engineering organization was to walk around the engineering floor in the late afternoon so he could note which of the developers wasn’t sitting at their desk writing code. In another executive team I was part of, the product direction would change 180 degrees in every quarterly review. I gave one of our strategic priorities the codename ‘Lazarus’ because it was publicly killed and resurrected so many times.

The only thing more predictable each quarter than the reversal of strategy was the scrutiny directed at “the developers.” This WSJ article about developers working two jobs only exacerbated many executives’ greatest fears. What are those developers doing anyway? How hard are they working? How do we know they aren’t moonlighting? I’m surprised chair manufacturers aren’t building IOT enhanced models with metrics to understand how long butts are physically in seats.

Alas, it’d be great if improving engineering efficiency could happen by simply chaining engineers to chairs, but as anyone who has ever tried to enforce draconian time management on engineers knows, it doesn’t work that way (and in fact is usually counterproductive.)

Like the drunk looking for his wallet, these executives keep obsessing over the part of the process they can see, regardless of whether it’s actually the site of the problem. In fact, most process waste comes upstream or downstream of engineering. For example:

A great engineer who is downstream of poor requirements will have a really hard time creating business value.

An amazing engineer without effective QA is working without a net.

We know this in our bones. In fact, many of these ideas seem obvious to the point of being cliche, and yet it’s all too common to forget them the moment it feels like we are falling behind in shipping software.

Understanding the efficiency of software development requires understanding the entire end to end flow of work to identify the places where it’s inefficient or misaligned with the business. Rather than simply walking around the engineering floor and taking attendance, this means understanding:

• Prioritization
• Requirements gathering
• Design
• Prototyping
• Engineering
• Unit Testing
• Integration Testing
• User Testing
• Deployment
• Bug tracking
• Maintenance
• Documentation

To make things even more challenging it’s not enough to understand these steps in isolation. As with any complex business process, the greatest risk of an issue comes in the handoff between the steps of the process, rather than in any particular functional area. And so, to improve software development, we need to understand the interplay between these different steps, and we need to understand each of these steps at a deep enough resolution and across time.

Software leaders know this to be true. They get that most of the sources of software waste come in the form of business process issues, not the mythical engineering fat that’s ready to be cut. These software leaders create ingenious spreadsheets hoping that excel and VB script will capture the interplay and dependencies across their extremely complex SDLC. And then they walk into their executive meeting and want to pull their hair out when they are asked “how many hours of work does each engineer do?” Or, even worse, “how many lines of code are they shipping.”

But, of course, understanding process flow objectively and comprehensively across each of these systems is complex. Doing so means not just integrating into upwards of a dozen different systems and mining the relational data contained within, but also stitching together the process flow across lots of different systems to understand how they are moving and where issues arise. This also means examining the ultimate “upstream” stakeholder of the product organization, the business executives who are ultimately responsible for setting the strategic direction of the company and thus the product priorities.

To understand and improve our SDLC, to avoid the human cost associated with bad software, we need to broaden our perspective. We need to own the business side of the equation, and understand that software development is a business process like any others, with inputs, outputs and internal work steps along the way. Doing so requires a much more thoughtful approach to software and thus harder, but the alternative is to keep looking in the same spot (and not really improving things) because that’s where the light is.