Good Architecture / Bad Architecture

Those of us in the software industry can at the very least agree that the pace of change in this industry is fast. A pessimist might call it constant change, an optimist might call it constant evolution. Either way, that also means that we’re really never in full agreement on what good software architecture really means. Otherwise why would we keep changing it so rapidly? What was good yesterday isn’t so good today, so we change it. Modern day web development is a very good example.

How it feels to learn JavaScript in 2016_No JavaScript frameworks were created during the writing of this article._medium.com

Change is constant in our industry because we are not in agreement on what good architecture is. When you hear someone refer to some software architecture as bad, what are they really saying? Is it that they believe that it could have approached performing the task better? Or that it performed well but was hard to maintain? Or that its structure was hard to comprehend? What made it bad?

Iterating is Coding and Coding is Iterating

We write software in iterations. It is similar to building a house in that there is a plan, a goal, a vision of what it would look like in the end. But when we build a building we don’t iterate. We absolutely follow a plan, but we build it brick by brick. We would never iterate by building a wall, then tearing it down, then building it again with a window, then tearing it down, then finally building it again with a window and a door. In software, however, that’s exactly how we do it. Software’s lack of physical manifestation affords us that iterative creative luxury. We get to evolve features in and out with each iteration.

The next iteration isn’t always about introducing new features. It’s more common that an iteration attempts to improve an existing set of steps to perform a task. Slowly but inevitably, the old code is considered bad in one aspect or another and the new code is good. That in itself is an assertion. The new code must be good, otherwise we would be intentionally creating bad code. I would argue, however, that it is neither.

Technical Debt

In our industry we hear the term Technical Debt way too often. It gets thrown around when coders lean back, geek out, and compare technical battle scars. Technical Debt is used to negatively describe a situation where good software architecture should have been implemented, but an unavoidable reason imposed itself and demanded that bad software be produced instead. The inference is that the good architecture will eventually need to be implemented at higher cost. That term, while indeed a catchy moniker, is too simplistic and in my view contrary to the spirit of iterative creativity. Essentially, acceptance and over application of the term Technical Debt may end up steering us away from what we really might consider good software.

The World Wide What?

Opining smugly that one should have strict data structure definitions is one example. Why would we tolerate any chance that our data have error-producing non-conformant structures? Wouldn’t building software that didn’t have such strict checks be Technical Debt that would cost us more later? Shouldn’t we just write it well (good) the first time around?

While that strict opinion sounds great, its misleading. Think of the difference between HTML and XHTML. Could the World Wide Web have been more successful if we all stood up and demanded that it be based on the good strictness of XHTML? Or would it have been more likely that rigidity — premature optimization — caused the early browsers to face so much more incompatibility that the whole thing wouldn’t have taken off at all.

The web, the internet, and e-commerce flourished despite HTML’s loosey-goosey approach. The fact that global society didn’t melt into chaos contradicts the premise of that strict opinion. Our culture as coders is full of these false absolutes that walk us down the path of good and bad labeling. A few years ago if you were an enlightened web developer you never mixed your HTML with your JavaScript. Smart, cool, thought-setters hovered among us like haloed angels dropping words of infinite wisdom preaching the gospel of presentation and logic separation and browbeating anyone who dared question their wisdom. Today…. ReactJS.

I’m wouldn’t claim it easy, but we should at least try to be brave and objectively, pragmatically, and sometimes courageously look at our choices and decide to choose for the right reasons despite what the cool kids say. What we’re being told is a Technical Debt might in fact be a Technical Asset.

Software architecture isn’t good or bad, it just is. It can and should evolve. When Windows XP came out did you hear anyone talk about how really bad Windows 1.0 was_?_ The arrival at Windows XP’s point in time doesn’t suddenly retroactively transform the previous versions of Windows into bad software architectures. It was just software.

Except for Windows Vista of course, that was indeed really bad software :P