Out of the Software Crisis: the ebook is imminent!

The book that is the culmination of my decade-long obsession with software quality is out now.

You can find the book’s website at: softwarecrisis.baldurbjarnason.com

Original blog post follows.

Software projects keep failing, not because we don’t have the right team or tools but because our software development system is broken. Out of the Software Crisis is a guide to fixing your software projects with systems-thinking making them more resilient to change and less likely to fail.

I’m about to publish my ebook, Out of the Software Crisis, very soon.

It is everything about software development I wish someone had told me a decade ago, condensed into a single book. It’s the “big picture” context that was missing in the first half of my career.

Putting it together has been a struggle. Publishing is always hard. I’ve been involved with, or adjacent to, publishing for over two decades now, and I still manage to be surprised by how tough it can be.

Even though I had a clear audience in mind, I had a hard time figuring out how to present it.

So, to help me make sense of it, I did the software thing, made a rough early version, got feedback, and iterated on it until it felt right. People have been incredibly helpful.

And it’s starting to feel right.

The book is an opinionated guide to applying systems thinking to software development.

For more information about it, including excerpts and a table of contents, there is now a book site: Out of the Software Crisis: Systems-Thinking for Software Projects. It links to a sign-up page for the release announcement.

Or, you can go to the sign-up page directly.

Excerpts from the book

Introduction

That is because the hardships have been lost in a haze of nostalgia. Software has always been bad. These apps may have been better designed, but they also didn’t have to account for as much variety in screen sizes or inputs. Most of them didn’t support proper multitasking, and stability was next to nonexistent. They crashed, a lot. Accessibility just wasn’t a thing. It’s like admiring the architecture of a classic building while forgetting that it’s a condemned deathtrap and every other building like it burned down, killing every inhabitant.

Try not to kill your software development system

The concept is that the world operates as multiple layers of interconnected systems and that the systems, not the elements of the system, are what defines overall behaviour and output.

A company’s performance isn’t down to the CEO or the employees but the system they operate in. A hospital’s overall effectiveness at healing people isn’t down to the skill of its doctors but how it’s organised and structured.

Much of the field is focused on theories on how you can change or modify systems—the levers you can pull to effect lasting change—but my focus here is simple: let’s try not to murder the system. We quite often begin with functioning development systems in software, and we don’t seem to have problems getting started. But we do have a knack for just absolutely murdering the hell out of the system afterwards.

Processes aren’t about managing the team or the project. They are feedback loops that provide elements of the system—in software that would be the team—with the information they need to adjust Flows and thereby affect Stock. The process’s effectiveness depends on the circumstance and how it connects to the rest of the system. There is no such thing as a prefabricated process. You always need to implement and adjust it to your needs. In software development, all processes work up to a point and in specific contexts. When in doubt, start simple and only add complexity if you absolutely have to. You may be told that you need to implement scrum or SAFe, but how you do it and hook it up to the rest of the system matters almost as much as the process itself. Details matter.

Variability is poison to software development

While defects are very important to any software project, the business benefit of unit tests is to preserve the future economic value of the code. This isn’t quite the same thing. Unit tests make the code resistant to being devalued by change. In software, the biggest threat to the economic value of code is that everything is always in flux. The business purpose of unit tests and types isn’t to prevent defects but to prevent variations in quality. Unexpected improvements in quality are just as undesirable as discovering a bug. Other modules may well be depending on the previous unimproved state. Unit tests serve as an early warning check that tells you something changed when it shouldn’t have.

Research & taste

I don’t care if you’re a backend developer, front-end developer, product manager, project manager, designer, or Swift/Java engineer, you need to collect good software, try it, experience it, and get to know what well-made feels like. You think a boom operator on a film set isn’t a film enthusiast? Half of them, easy, can recite the best lines from Coppola’s The Conversaton from memory.

Programming as theory-building

Software is the insights of the development team made manifest. Software has no life on its own but exists as a kind of cyborg simultaneously in the programmers and the code. To reuse Donna Haraway’s words, software is simultaneously fiercely material and irreducibly imaginary (p. xii, Gray 1995). Software can be real and unreal at the same time. The written code is how software interacts with end users and other software systems. The insights and knowledge that exist in the minds of the developers are how software lives, changes, and grows. Without the code, it has no way to interact with the real world. Without the knowledge in the minds of the developers, it has no way to adapt and survive.

Maturity, Complexity, & Layers

This is the flip side of the maturity question. Many mature frameworks have evolved alongside their exemplars—the apps and software that exemplify how the framework should be used. When you attempt to build something similar using that same framework, you will often fail miserably because you are trying to extend a complex system with complex interactions. The exemplary apps won’t have the same problem because the system was simple when their projects began and grew with it. This is a frequent issue with single-vendor frameworks. Whenever you have a framework whose primary purpose is to support a single product or service, you often end up with interwoven complexity that makes using it for a new service much harder.