Those of us in the 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 software really means. Otherwise why would we keep changing it so rapidly? What was yesterday isn’t so today, so we change it. . software good architecture good good Modern day web development is a very good example _No JavaScript frameworks were created during the writing of this article._medium.com How it feels to learn JavaScript in 2016 Change is constant in our industry because we are not in agreement on what architecture is. When you hear someone refer to some software architecture as , 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 ? good bad 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 in one aspect or another and the new code is . That in itself is an assertion. The new code must be , otherwise we would be intentionally creating code. I would argue, however, that it is neither. bad good good bad Technical Debt In our industry we hear the term 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 software architecture should have been implemented, but an unavoidable reason imposed itself and demanded that software be produced instead. The inference is that the 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 software. Technical Debt good bad good good 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 ( the first time around? good) 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 strictness of XHTML? Or would it have been more likely that rigidity — — caused the early browsers to face so much more incompatibility that the whole thing wouldn’t have taken off at all. good premature optimization 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 and 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. good bad 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 or , it just is. It can and should evolve. When Windows XP came out did you hear anyone talk about how really Windows 1.0 was_?_ The arrival at Windows XP’s point in time doesn’t suddenly retroactively transform the previous versions of Windows into software architectures. It was just software. good bad bad bad Except for Windows Vista of course, that was indeed really software :P bad
