Author: neopragma

I’m seeing a lot of talk online about agile software development – what it is, what it used to be, what it’s supposed to be, whether it’s dead or alive, how we can design better agile frameworks, etc. Maybe the subject isn’t being discussed broadly, but I’m connected with so many “agile” people that it gets a lot of play in my feeds. I get the feeling people are beating up a rag doll, or flogging a dead horse, if you like old sayings.

I think there are three converging trends that are quickly making the whole subject moot.

You’ve probably heard advice from certain quarters that a software developer doesn’t need a pointing device. Everything they need to do can be done with the keyboard, and the work is much faster that way.

The advice seems succinct until you unpack some of the underlying assumptions. Besides that, I think we should think about the effect on novice developers when highly-experienced trainers and coaches tell them to throw away their mouse. They often end up spouting off on their blogs about how anyone who ever reaches for a mouse for any reason is unprofessional.

They have been told by mentors they respect that they don’t need a mouse. All they need is a keyboard. And they’ve practiced working that way through code katas and other exercises. They can navigate their favorite text editor flawlessly using the keyboard alone.

Year by year, the general quality of software worldwide, in every industry, declines. Software testing specialists lament the low quality of applications they use in their regular lives as well as those they are engaged to test.

It has become a sort of game to take photos of crashed billboards, kiosks, train and bus signage, and other software failures and post them online. The examples are called Kevlin Henneys, after a software engineer who started posting such photos several years ago. They’re amusing, but also lead one to wonder why software failures are so common, and how we came to accept bad software as normal.

I don’t claim to know all the causes of the phenomenon. One cause may be the sheer number of people involved with developing software. It’s been said that the number of programmers in the world has doubled every five years since about 1970. That may or may not be absolutely accurate, but in any case the key observation is that half the people writing the software products we depend on in our lives have less than five years experience.

Many of them never learn software development as an engineering discipline. They are graduates of rapid learning programs such as “bootcamps,” aimed at enabling a person to generate a mostly-boilerplate mobile app or web app quickly. Intuitively, this looks like it could be one cause of poor software quality.

But I’m exploring another possible cause in this post: The obsessive, almost manic preoccupation with delivery.

I’ve heard it said that sometimes we learn a different way of looking at things, and it influences the way we see the world from that point forward.

For me, one such way of looking at things is Lean Thinking. I became aware of that school of thought about fifteen years ago, and it had a profound effect on the way I approached my work in software consulting and team coaching.

As I learned more about Lean, it became the default lens through which I viewed software development and support processes. It changed the way I think about two concepts that people talk about a lot: value and waste.

My observation is there are two kinds of value and most people don’t distinguish them. Similarly, there are two kinds of waste and most people don’t distinguish them. One of the kinds of value overlaps with one of the kinds of waste. As a result, in many organizations people emphasize the wrong kind of value, while simultaneously treating some forms of waste as “value.”