What we are paying attention to shapes what we perceive and pay attention to. And paying attention, requires attention. The system, thought of, observed and measured, reasoned about, designed as, a system, needs intentional attention. Attention that competes for bandwidth with the order of the day — delivery of working code (with tests, please). We need to discover on purpose (embracing happy accident along the way), design on purpose (embracing iteration, discovery, accident), and… redesign on purpose (throughout the lifecycle). Using the cheapest design medium that will expose the uncertainties and stress the design (fragment, mechanism, etc.) under consideration sufficiently for the (extraordinary!) moment we’re at. Which may be code. But don’t assume so, when thought experiments, models, sketch-prototypes, cardboard mockups, role-plays, etc. will serve the moment. Yes, yes, “code wins arguments,” but you have to know how to set up your arguments.
The system takes a different kind of attention. Thinking at the interaction between capabilities (and value the system delivers) and system properties (impacting users individually, like usability and performance, and in aggregate, like scalability and availability; and impacting operations and the business, …) and the structures and mechanisms that deliver them, takes a vantage point that is able to move fluidly and adeptly at different scales or scopes (zoom levels, if you like) and across views (frames, cross sections, selective screening, …). But it also takes time, which takes will — the organizational will, and the personal will, to do it. When there is code to be written, and pressure to deliver. Increasing. If we build ourselves into a blind-alley of “technical debt” …which I have come to think of as “decision debt” — where we put off making a decision and the non-decision decision (do nothing, or keeping doing the old thing) or a reactive quick-fix decision gets coupled into the system. Some of these will be of little consequence. But there will be those where the “payback time” comes with stiff interest — and penalties! (Those are the ones an architect should have sniffed out as architecturally significant — and if he didn’t, he will next time! Experience factors. Puns allowed. We’re among friends.)
But wait. We can refactor. Continuously refactor. That’d do it. Well, yes. And no. Imperious Red Queen voice: “I need an architect here… Architect?” “It depends.” What did the Red Queen tell Alice? “it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” Say what?
Someone needs to be thinking strategically about the system. Not alone; working with the team, but having responsibility for the system so that attention is drawn to the system, attending to structural integrity in the small, sure, but in the large, too. Instrumenting the system — making code health and operational health visible. Anticipating the market and problems in the code, keeping tabs on how the system is doing relative to the design envelope for its various system properties. Finding the weak spots in the design. And doing “model storming” “out loud” “in pairs” or small groups. And all that agile stuff. Just in the cheapest medium for the moment, because we need to explore options quick and dirty. Hack them — with sketches/models, with mockups, with just-enough prototypes. Enough early. And enough along the way so that we course correct when we need to. So that we anticipate enough. Put in infrastructure in good time. Avoid getting coupled to assumptions that cement the project into expectations that are honed for too narrow a customer need/group. And suchness.
