Computers Can Be Understood
I am a senior software architect. My job is to balance performance against complexity.<p>If my system is slow, it&#x27;s my fault.<p>If debugging or expanding the system is too difficult, it&#x27;s my fault.<p>If someone wants to know how the system or business works in depth, I am the one that they should come to.<p>I spend the majority of my time chasing down, enforcing, and simplifying the universal theory of our business (the core of our software solution).<p>The universal theory of our business is a living collection of concepts, designed to accurately model non-virtual concerns in virtual space. If there are too many edge cases, it is a sign that the universal theory is inaccurate, or not robust enough in some areas. If there are too many bugs, it is a sign that the universal theory has not been communicated or enforced well enough, is inaccurate, or is too complex in some areas. As our business grows, or our understanding of the business expands, the universal theory will change; at times dramatically. Malleability (the ability to adapt our software to these changes effectively and efficiently) is one of my top two concerns; the other is latency (how long it takes for any one request to get a complete response).<p>The theory shrinks and becomes better documented as it evolves; the goal is to move from describing behaviors as correlation to describing them as accurate causation. To fill in the blanks.<p>I should mention here that this does not mean every line of code in my projects is easy to understand. Writing a fast system of high complexity requires at least some components that are written exclusively for the computer&#x27;s benefit (that is, highly optimized and inherently difficult to read). These components should be written with clear documentation, clearly defined public members, written discussions of why it works the way it does (and common ways to accidentally break it), redundant ownership, and regular auditing to ensure code rot is avoided.<p>I have yet to meet another architect that sees their job the way I see mine.<p>If the system you&#x27;re working on defies complete understanding, you can probably blame your architect.