As a very brief reintroduction to my first article in the MoneyCode series, here’s the essence boiled down to a single question:
How do software engineers deliver more quality value faster?
The first article of the series concentrated on delivery. Specifically, getting software into production really is the only thing that matters. Without it going to production, there’s really no reason to develop it in the first place.
But production delivery in and of itself really doesn’t tell the whole story. Low quality in production really has no value for delivery at all. Therefore, focusing on quality in production has to happen.
Quality
That word has all kinds of reasons for being important.
After all, ask five different engineers what they think quality means, and you’ll get five different answers—albeit with similar themes.
In the end, it’s still a money game when you talk about quality. Here are are some of the different things I’ve heard used to define quality in software:
- Customer Experience
- Quality means reacting to the customer’s needs in real time.
- Customers love you, because you love them.
- Very Low Defect: Feature Ratio
- When customers use the software, they don’t find defects. Instead, they hold up your software as an example, saying: “Why can’t everyone make software this stable?”
- User Experience
- Customers love using the software and interface. It’s fast, it’s easy, and it’s just fun to use. It’s neat and simple.
See what I mean? Quality can mean lots of things. And all of these things translate to the bottom line for the company or client, which translates to dollars in your pocket as you help to improve these (or many other) metrics.
Notice: Quality Does Not Mean Perfection
In my list of things I’ve discussed with others about quality, none of them ever seem to bring up the idea that quality equates to perfect software. There’s a reason for this.
I have a product manager right now who really likes this phrase:
“Perfect is the natural enemy of good enough.”
Here’s what he means in a simple diagram (I like to draw on boards and debate the merits of the concept with anyone who’s willing to listen to me):
This diagram shows that often, if we pursue the perfect solution, we’re wasting tons of time and money that we could have spent just getting to good enough. This is usually the case.
If you get lucky, sometimes “Perfect” and “Good Enough” actually overlap with one another—so in the pursuit of perfect you’ll land in the “good enough” zone and not have wasted a ton of money getting there.
However, targeting “perfect” sometimes has a nasty negative consequence. Hang on to your drawstrings everyone—here comes the economic lesson about marginal revenue and marginal cost!
Marginal Revenue and Cost
I’ve tried to define these as succinctly as possible, while still ensuring that my economics professors won’t try to hunt me down and take the life of my firstborn:
- Marginal Revenue
- The amount of additional income earned by improving the solution incrementally towards the goal of “perfect” beyond the boundaries of “good enough”
- Marginal Cost
- The amount spent on engineering time and testing time incrementally pushing the solution towards the goal of “perfect” outside the boundary of “good enough”
I promise I’m not spewing gibberish. In fact, in economic optimization, there’s this cool concept of a revenue curve and a cost curve. Where they intersect, that’s where you stop and call your solution optimized.
Granted, in the economic theory I learned, this model was applied to the number of widgets sold or number of hours to operate a business. However, the lesson carries over to software too. Look. Graphs!
The graph has a lot of stuff in it, so let me break it down a bit further for you.
- Marginal Revenue (downward green line)
- The amount of revenue—actual dollars on the bottom line—earned, per quality line of code written.
- Lines of Code is a horrible metric. Quality lines of code is a fantastic metric. It’s much more subjective than just “number of characters in a source file”.
- The amount of revenue—actual dollars on the bottom line—earned, per quality line of code written.
- Marginal Cost (upward red curve)
- The amount of spending—actual dollars paid to engineers—per quality line of code written.
- Again, lines of code doesn’t tell you anything about cost by itself. Cost of quality lines of code really serves as the best metric here, as well.
- The amount of spending—actual dollars paid to engineers—per quality line of code written.
- Profit Maximization (blue rectangle)
- When the amount of money earned per quality line of code written is exactly equal to the amount of money spent creating that line of code, profit has been maximized. Any less written code is a loss of additional revenue. Any more written code costs more than it earns, and reduces profit.
- The Perfection Gap (bracket at the end)
- Perfect can often be so far away from the profit-optimized solution that shooting for perfect code can lead to a net operating loss. No company can operate sustainably in this fashion.
Please keep in mind—this is a very high-level crash course on one very small portion of microeconomic theory. I don’t expect you to grasp it fully by reading this one article—so please review some additional resources. I really like this one at Khan Academy.
If you skipped all of the economics lesson stuff, here’s the key takeaway: Perfection is economically infeasible, and there’s good economic theory that explains why.
So, if quality != perfection—let’s circle back to those things that make more sense to explain what quality is.
Enthusiastic Customers—What’s the Customer Experience?
So, what’s an enthusiastic customer, and how does it have anything to do with quality?
“It takes years to win a customer and only seconds to lose one” – Catherine DeVry
If you don’t take the time to put customers’ expectations first, then be prepared to lose them.
We cannot possibly know whether we’re providing the right kinds of value if we don’t know what our customers think of the software solutions we provide.
There’s all kinds of analytical metrics that allow us to see how our software gets used and, more importantly, how heavily. We need to concentrate on making the most used stuff the most impressive. The least used stuff, well, it probably needs to go away entirely.
To do this, we have to get feedback from customers constantly and quickly. Additionally, we have to be able to react to it with relative ease, to ensure they like what they see when they contact us.
One company in particular really seems to know how to give customers exactly what they want, to the point they decide to “Get Inked.”
If you want to hold up one example of customer enthusiasm, look at Harley Davidson. I’m not sure I really understand the phenomenon, but customer love for Harley-Davidson seems to go way beyond having the best motorcycle in the business. Many people who love their Harley will happily get the brand logo “inked” forever on their body.
I find it absolutely incredible that people will go out of their way to make it obvious that they really love their Harley. Especially considering the fact that they have a Harley tattoo, yet also gripe about their bikes breaking down. Again. Go figure. That’s what I mean by customer experience. Customers don’t care about the maintenance factor when they can say “It’s a Harley!”
Avoiding New Defects When Creating New Features
Whether you have a reality distortion field or you’re a company whose customers are tattooing your name on their bodies, one common thread you’ll find is the constant drive to reduce the number of defects created any time code changes.
This is the Low Defect : Features reason I noted above.
It has a pretty steep cost curve associated with it at first. Getting a useful regression protection suite in place will often at least double—sometimes more than double—the usable lines of code written by the engineering staff.
Yet, many managers aren’t willing to pay that upfront cost to reduce their overall defect ratio.
It’s because they’re favoring “accounting cost” (the actual dollars and cents on the ledger) over “opportunity cost” (the loss of opportunities to be better). Instead of spending more money now to protect against regression, they’re seeing delivery of features as the driving factor instead of delivery of defect reduction.
What they don’t realize is that it’s pretty much a situation of robbing Peter to pay Paul. And usually, when you go to pay Paul, you’re paying him way more than the original amount you stole from Peter.
Manual regression testing is expensive and time-consuming. It should be the least popular of all of the testing solutions used, but so often it’s still the most commonly implemented one.
If I get on a soapbox about any one thing, it’s having a high-quality regression protection suite.
Yes, it has a high initial cost. But after one use, it becomes a primarily fixed cost (excepting the cost of adding more tests or updating failing tests).
Every time you run the test from here out, the average cost of testing each line of code dramatically declines. Especially compared to what it costs to test it manually.
Reality Distortion Field Engaged
Many people have talked about Apple’s “reality distortion field”—and let me tell you, it’s powerful.
Those people love Apple really really really really… I mean really, seriously, truly… love Apple. They put Apple stickers on their cars, for crying out loud!
And yet, here I am, writing this on an Apple product. I promise you, it’s just hardware. It’s very nice hardware, but it’s just hardware.
I have problems using the Apple ecosystem just as much as I do the Google/Android ecosystem or the Microsoft ecosystem.
The difference with Apple is that they make the overall user experience stupidly easy. They go above and beyond to make the experience so fantastic that the users can overlook the fact that Apple really isn’t all that much different than other hardware/software vendors.
If you make the User Experience (not to be confused with Customer Experience) part of your quality threshold, you end up at Apple somewhere along the way.
What differentiates User Experience from Customer Experience is a very clear boundary, even though both terms have the word “Experience” in them. Customer experience means, simply—the impression your customers have when they interact with your team. User experience means, simply—the kinds of impressions your customers have interacting with your product: software.
When you truly put your customers’ wow factor first, they’ll tell you to shut up and take their money. Because after all, everyone wants a shiny Apple, right?
Also—no offense intended to anyone that swears by Apple above all else. It’s a topic that I know very well, and many people think that Apple, as developers, trump just about everything else. I just don’t happen to be one of them. My Macbook is provided by my employer. Otherwise I’m pretty ecosystem agnostic.
Quality—Don’t Leave Code Without It
I once worked indirectly under a high-level executive that liked to use the saying: “If we don’t have time to do it right, when will we have time to do it twice?”
Get the code right the first time.
But make sure that the version of “right” you’re targeting falls into the realm of “good enough”. That way, you and your team will be profit-maximizing, quality code-producing machines.
Your customers will love you for it.
And you’ll love yourselves for it, because you’ve made it easy to keep making cool things happen for the people that need them.
At the end of the day, if you can make quality (however you and your team define it) an important driver in your mission, money will show up in your pocket.
Quality software means dollars on the bottom line.
And if you positively impact dollars on the bottom line, you positively impact dollars in your pocket. Quality has to be a huge part of your internal drive towards your own MoneyCode.