When something persists, some reward exists
Jason Gorman has just written a piece in defense of Software Craftsmanship that highlights how very dependent our world has become on software. He offers Gorman’s Law Of Software-Dependent Business Evolution:
Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to.
I think this is not only true, but an incredible opportunity for businesses that understand that. Let’s face it: most businesses spend an awful lot of time for a very meager increase in systems capability. Companies that do better than average can shoot to the top. Look at the spectacular successes of some of the relatively young internet companies, for examples.
As Corey Haines points out, we, as an industry, know how to produce relatively bug-free software in a steady stream, delivering needed functionality early and often to businesses starved for capability. But, for the most part, the IT industry doesn’t do so.
Jason’s proposals for addressing this gap fall short, in my opinion. The first, that getting more kids to choose software development as a career, seems odd to me. I don’t think we’ve got a lack of people. I think we’ve got a lack of people who know and practice the techniques that we, as an industry, have found to work. The second, getting more practioners to want to do better, addresses this lack. I’m all in favor of this, but I don’t think it, alone, will make much of a dent in the overall situation.
Even if we’ve got excellent software craftsmen, if the quality isn’t demonstrably valued by their organization, they’re most likely to either get demoralized and slack off their efforts, or leave that organization for greener pastures. So, while I do think that most software developers need to improve their skills (and continue to do so over their entire career), I don’t think that will drive improvement in those organizations that need it most.
Organizations, like most systems composed of people, tend to develop amazingly stable patterns of operation. These patterns persist through reorganizations and changes in personnel. The reason they persist, is that there is an informal network of effects that regulate the system, putting and keeping it in its current state. This stability doesn’t happen without forces reinforcing the behavioral patterns and inhibiting other behavioral patterns.
The study of these patterns and the forces that reinforce them is called Systems Thinking. You can read more about it in Peter Senge’s The Fifth Discipline, Jerry Weinberg’s Quality Software Management: Systems Thinking, or An Introduction to General Systems Thinking, among others.
A fundamental lesson I’ve learned from Systems Thinking is that when some behavior persists over time, there’s something that’s rewarding it in some fashion (perhaps unintentionally). If the behavior doesn’t make sense to me, or seems counterproductive, then I often find it more productive to look for what that reward might be rather than plead harder for a different behavior.
In this case, I think that large organizations operate in ways that support doing a slapdash job of software development. I’ve seen many organizations that primarily reward behavior that’s irrelevant to helping them evolve more rapidly. That and simple neglect of the behavior that would aid being more nimble in the marketplace are enough to produce the stability of the systems I see.
Many of these instances of rewarding irrelevant behavior come down to focusing on costs (which are easy to quantify) at the expense of value (which is much harder to quantify). To promote the development of higher quality, more valuable software, I think we need to make that value more visible to the decision-makers. They’re not stupid, after all. They’re just working with the information they have.
What other drivers do you see behind the vast sea of mediocre software production?