Software doesn’t go bad over night. Like cancer, a whole tumor doesn’t just materialize in the body in an instant. An entire system isn’t pervasively compromised in a single spasm.

Software cancer starts at a single cell. The time to deal with it is when it’s still a single cell. Otherwise, it will expand exponentially until it pervades every aspect of a system and can’t be controlled.

Even when software is suffused with cancerous tendrils pervading every aspect of a system, developers may still not recognize that it’s there.

We’ve become so complacent with unhealthy software design that we’ve entangled the very identity of software developer with the ability to tough it out and laugh it off. At our worst, we even demean and deride the very body of knowledge that is specifically constructed to allow us to avoid the cancer, and to detect it at its earliest stages.

Software design and its four pillars, namely design principles, design qualities (and their metrics), design patterns, and design process, are typically not understood well-enough at large to put them into moment-by-moment practice. Most developers have a passing familiarity with some of the names of some of the principles, for example, but don’t really have a full grasp of them, or how to use them as concrete and tangible tools.

It’s these tools that are the mental guardrails that protect our work from problems that we can’t afford. The challenge is that, continuing the analogy, software design defects are effectively invisible to the unaccustomed eye. They exist at a level the isn’t made readily-apparent by merely looking at the code, not unless the developer is already well-practiced in the software design body of knowledge and practice.

Software design is the science of programming. Design qualities, design patterns, and design process build upon each other, and together form the early detection system that identifies and then eradicates cancer while it is still within our power to control. It’s an instrument like a microscope that allows us to see things that the naked eye might ordinarily disregard while the mind is fixed on more tangible and concrete aspects of getting the software to just work at all.

The science of software design teaches us which things we do in software development are mistakes. And it also informs us why a take-no-prisoners stance toward design mistakes is critical to maintaining healthy software, and why even a single cancer cell must be dealt with.

But software design isn’t microscopic. Software design is subtle. And because it’s subtle, it’s a lot easier to miss the mistakes.

It’s the mistakes that are the cancer. Design mistakes may have no effect on the operation of a software system or software application’s features. Design mistakes don’t always result in malfunctions of the software. Design mistakes result in malfunctions of the software team and the software project.

The subtle mistakes in this subtle realm compound upon each other exponentially until software gets to the point where we can no longer make progress with it at a pace that we’d want, and that business leaders expect.

And we laugh it off. We say it’s an inevitable outcome of software, and that it’s part of software’s inherent nature. And worse, we disregard the fact that our ability to make progress continues to decline as we continue to put our hands on our code.

We reject the very possibility that microscopic influences could have any effect on our codebases irrespective of the fact that our codebases are assembled from countless numbers of them.

But software codebases and software projects don’t just go from being healthy one day to being riddled with terminal cancer the next. That cycle of decline and decay isn’t part of software’s nature at all.

There isn’t a single atom or iota of disease that finds its way into the body of software that isn’t put there by developers. It might be done by negligence or by ignorance or even by cynical science denial, but this is the inescapable nature and reality of software.

There are no evil elves that sneak into our repos in the middle of the night and wreck havoc on the good code we left there at the end of the day. If code goes bad, it’s because we set that decay into motion. If the implementation gets better, that’s to our credit. If it gets worse, that responsibility rests only with us software developers. If we proceed to do nothing about it and even disregard the very body of knowledge that we’re supposed to be armed with in order to save of such effects, that’s on our shoulders.

There isn’t a troubled software project in existence whose troubles aren’t complicated and multiplied by design mistakes. There isn’t a team that’s struggling with lower-than-expected productivity that hasn’t disregarded the design science of programming to some degree believing that it’s an innocent gambit.

The best cure for software cancer not surprisingly is prevention. And if not prevention, early detection. Cynicism toward software design and brute force heroism and bravado are just unhealthy coping mechanisms that engender more calcification and the need to justify yet more science denial.

The cure is to put software design, it’s qualities, principles, patterns, and processes front and center in every decision about every line of code, and to leverage software design as a purposeful act engaged with our full attention.