Bad Software, Written Badly

Thinking about software, economics, and the things I care about.

This article may not be particularly coherent, if any of my articles ever are, because I’m writing it to find out what I think. So, as I so often do with software, I’ll be following my nose.

I’m starting from a motion that GeePaw Hill has often expressed:

Companies can make so much money from shipping bad software written badly that it makes no sense to optimize the way they work.

Is that true?

It sure seems to be true, because as coaches we know how poorly written a lot of software is, and how dysfunctional the team aspects of the work is, and yet the companies are successful, often amazingly so.

What makes it true?

The market for almost any kind of software is huge. Much of the world is connected. People everywhere seem to have smart phones and computers. There are billions of people, and thousands of potential users for almost any software we can imagine. Meanwhile, more and more software can be produced by smaller and smaller teams, and even if it takes a thousand programmers to produce a product, that is still far fewer than the potential customers for the software. Since distribution costs are near zero for software, almost all the cost of the product comes from marketing, sales, support, and development, all of which add up to far less than the value of the market.

Note: I can quibble with that point, and so can you. The same will be true with whatever I write below. We’re not shooting for absolute accuracy: we’re trying to get the picture. (What does the fact that I’m consciously accepting inaccuracy and more or less random development of this article tell us about the topic? (Perhaps nothing: no one is likely to pay me for this article.))

What is the value of our approach?

By “our approach”, I mean, roughly, the notion of a cohesive team of “makers, making the made”, a team with all the skills and authority to decide what to do and to do it, using the practices we have found to be valuable, such as TDD and Refactoring. I use the phrase “new way” below, although our way is not all that new.

We hold that the approach we use creates better software faster than what is commonly done today, and that it is more enjoyable for the team, more visible to the company, and, because it produces better software faster, more profitable. We will assume for the sake of this article that this is true.

The ideas we offer will make it easier and more joyful and more profitable for the organizations that use them.

What is the cost of our approach?

Interesting question. Creating self-organizing teams requires a real change to an organization’s thinking. It requires pushing decisions downward in the organization, something that is anathema to many managers. It requires people to collaborate, which is new to many, and often quite a surprise for software developers, who often work alone. The specific techniques and practices that we espouse do take time to learn, and they are quite different from what developers are used to, and in fact quite different from what developers often believe the practices are. The phrase “you’re doing it wrong” is all too often true. It takes a long time to learn to do it really well, although some benefit comes early on. I continue to learn after over two decades of working in this fashion.

There might be an economic cost to working this way, for a short period of time, as the organization learns how to do it. This cost could be minimized by transitioning a few people at a time, but, of course, that would also defer any benefit and often make it hard to see the benefit. What good is it if Team A is able to go faster, when their releases are all shackled to Teams B, C, and D, which are still working at the old, slower pace?

I think, though, that the emotional cost is larger. If we look at a group of people working in the fashion we propose, they are operating differently from the organization they’re embedded in. The people on the edges of that team need to accommodate this new way of working. They need to change. They didn’t ask to change, they are just faced with the need to change in order to deal with this strange new thing in their midst. All too often, rather than change, they kill the thing. Solved, no change needed.

And if they do not kill the new thing, are not permitted to kill it, they may still refuse to change. For example, imagine a newer much faster way of producing health-related software. The organization that produces this software has a large and powerful safety organization, monitoring the work inside and managing the relationship with outside regulators. the safety team will generally rely on a long and bureaucratic process of checks and balances, designs and cross-checking, and so on.

It is perfectly possible to satisfy both the real safety needs and the regulators’ requirements using our approach. We know companies that do it. And those companies had to learn how to do it, and it was not easy. As long as the big bureaucratic process endures, the organization will not get the benefits of our approach. Our approach will be seen as having failed, and it is likely to die out or to be put to death.

The cost of our process is change, and change is hard. It’s not an economic cost, it’s much worse: it’s a human emotional cost.

What can we do about that cost?

If the emotional cost of using our ideas is in fact a major impediment, then clearly we need to reduce that cost. We would need to make the changes easier. This might be done by adopting the ideas slowly, very incrementally. We do not like this idea: we are impatient, because people are suffering and bad work is being done. Still, it might be necessary.

We might be able to reduce the emotional cost using a process that I don’t want to call “marketing” but it might be the right word. People working in the “old way” have certain practices and expectations about software development. If we could cause them to understand that they could expect other, better things, things that a “new way” team could provide, they might be more ready to deal with a “new way” team.

This approach is fraught. The “promise” of Scrum, “Twice the Work in Half the Time” often leads directly to disappointment with Scrum. See this article, for example. An organization’s teams have to learn how to meet the expectations that are proper to them, and those with the expectations need to learn that there will be a learning period, often showing little progress over the “old way”.

Why do we care?

Darn good question. I can answer only for myself. I have worked in this “new way”, sometimes with just parts of it, sometimes with all, and those have been the most enjoyable times of my work life. The team had shared goals that they believed in, they collaborated well together, the program grew rapidly, the code worked, and it was mostly good. (It’s never perfect. We can always improve.)

I see development teams who do not enjoy their work, or who enjoy it only rarely or only a little. I want them not to suffer; I want them to find the joy in their work that I have often found in mine.

Do I care about corporate profits? Not much, to tell you the truth, except to the extent that they support the lives and joy of the workers. No, I’m not a commie pinko. Not even a socialist. I’m just some guy who thinks that the folx who do the work deserve just as much of a chance at a decent life and a joyful existence as the mostly luck-supported people at the top of the pyramid. I think that the money and the joy should be more equally distributed. I think that humanity has the capacity to accomplish that. I’m not even sure it would cost anyone their yacht that’s so big they almost had to tear down a bridge to move it. I’m not saying everyone needs a yacht, and I’m not saying no one can have one.

I am saying that everyone deserves a decent home, decent food, decent education, decent health care, decent entertainment, decent connectivity, a perfectly reasonable and full life. And I think humanity has the capacity to bring that about.

But I digress. My purpose in this endeavor is to help software developers to do their work in a way that benefits them both economically and emotionally. It happens that doing that will benefit the organization they’re in, and I am just fine with that.

What should we do?

Well, you see what I do in response to my own “why do I care”. I write mostly to developers, and I write mostly about the way I do things, and how it affects me in terms of productivity, but more, in terms of how I feel about the work. I work this way and I get tense. I work that way and I feel joy. I try to work more that way and less this way.

Do I think that other developers would get a similar effect of more joy if they worked as I do? Not exactly: some of what I do is conditioned by the fact that I can defer the next features as long as I want, so that I can go down a long refactoring rat hole if I wish. But I do think that by considering how I work, and drawing lessons from it, a developer might begin to focus on her own practices and techniques and would likely find her way to a way of working that brings her more joy … and more productivity.

So, to the extent that my colleagues care about what we often call “geek joy”, maybe we need to find new and better ways to bring our ideas before developers, in ways that are affordable, enticing, helpful, and valuable.

The extended family of my colleagues surely cares about more people than the developers on whom I focus. Some of my friends and associates care about different aspects of the work, in particular teamwork, about which I write only seldom. I care about teamwork: it’s just that there is no team in my room here chez Ron. Some of my gang care about testers, or product management, or interface design … any of the panoply of topics without which good software is impossible. And for each of these areas, they, too, need to figure out how to better bring their ideas before those who can benefit from hearing them.

I have it easy. I am old, retired, and have probably already bought my last BMW. While my health and money holds out, I can do this every day, because if I have a day job, this is it. My colleagues, much younger than I, for which I envy them, often need to earn money, for which I do not envy them. So their approach will need to be different from mine, conditioned by their interests and their needs.

Sort of a Conclusion?

At this writing, I think that a lot of what we may need is to find ways to bring specific ideas of value to the specific people who can benefit from those ideas. Each such idea probably needs to be atomic, in the sense that they provide benefit, even if only in terms of joy, to the people who adopt the idea, and do no harm to their other needs or those of the organization they’re in.

My doctor once suggested that I try a supplement to deal with some condition or other. His words were “Can’t hurt, might help”. That’s how our ideas need to be parceled out, in a form that will likely help, and that cannot do harm.

I’m sure I’ll have more questions, and I hope I get better answers. You can help, if you care to, by writing me a note or a toot. Don’t try to reach me on Xitter: I don’t go there any more.

See you soon!