Get Your Architecture Right, Because You Always Have More Time than You Think You Do
When facing an anxiety-provoking deadline for a software project, you have more time to plan your architecture than it may seem. Indeed, you should consider near and medium term requirements and risks to the full extent that it is possible to consider them given current knowledge, even if you choose not address any of them up front. Take only calculated risks. Factor those risks carefully into your initial implementation. Do not touch a keyboard until you have done so. Cut corners, but cut them thoughtfully.
Urgency Versus Anxiety
It’s worth noting the important difference between a sense of urgency and anxiety. Before I got into software development I was a registered nurse in an ICU. One evening a patient went into cardiac arrest. In an instant, the room filled with nurses and other folks eager to jump in and help. I was leaning over the patient’s bed giving chest compressions to keep the patient’s blood flowing. I felt myself swarmed by a small crowd in scrubs and Crocs. There were more people present than necessary, and it made the atmosphere in the room ratchet up from an appropriate urgency to a palpable anxiety. A supervising physician on the scene wisely ordered everyone not currently providing care to leave the room. As the excess folks filed out, I overheard the physician mention something to a colleague about the dangerous anxiety he was correcting:
I’ll never forget something an instructor told me in med school about situations like this, “You always have more time than you think you do.”
He wasn’t addressing me directly, but the lesson stuck: there will never be a medical situation so dire that you literally cannot spare a moment to consider an appropriate course of action. There’s no use for anxiety in the mind of a professional doing his or her duty in a crisis. March all the unnecessary anxious thoughts out of your mind and make room for a deliberate response. Give yourself permission to think. In the years since that day, I’ve found this lesson to be very valuable, even outside of healthcare. Strange as it may seem, I hear echoes of it in my process for sketching out architectural roadmaps for the applications I work on.
(Fr)agile
In an ideal world, agile processes are adhered to with perpetual regularity, pulsing in a cadence of small, iterative changes. In the real world, an organization that can unwaveringly adhere to an agile process is hard to come by. Customer demands, public events, and other factors create constraints that require setting a fixed ship date for a product launch. This is lethal to an agile process because there’s no margin of error for iteration. You don’t have the luxury of repeated revisions. You barely have time to ship your first draft. Under these conditions, the anxiety of the engineers on such a project skyrockets. Facing a tall list of requirements and a fast-approaching, narrow delivery window, there is a temptation to bust out the keyboards and hammer out some code because how will we ever finish unless we can show immediate and significant progress oh god oh god. Invariably, code written in thoughtless haste is unmaintainable or, worse, unshippable. Technical debt is accumulated at an unacceptable rate. Inappropriate patterns are chosen and implemented haphazardly.
Breaking it Down
It is difficult to break a down a set of large problems into atomic problem units which can be distributed among a team of developers and solved in parallel. In a healthy agile process, there is no single delivery date, but an ongoing process of experimentation and refinement. Impedance mismatches between the output of developers working on separate components are addressed through repeated course corrections. You fully roll out a feature only when it’s ready to be. But when there’s an aggressive and fixed delivery date, there’s no room in the process for such refinements. Each component has to be shippable in its first iteration, and it has to immediately lock into place alongside all the other components.
Under the pressure of a looming deadline, developers may spend an inadequate amount of time considering their architectural roadmap. At worst, this leads to a code base that fails to satisfy the launch-day product requirements on time. At best, the code produced is ill-suited for the life of the product immediately after launch. There’s no agile process in place to carry it through future milestones, so the cycle of fixed delivery deadlines and frantic architectural changes repeats until the product fails.
Here’s a metaphor for the problem. Consider an illustrator tasked with drawing a human figure. A trained illustrator works like this:
She begins with gesture lines and primitive shapes, blocking out the pose, proportions, and perspective. Progressive levels of detail are added, guided by those initial lines and shapes, until the drawing arrives at its intended appearance. Inexperienced artists try to begin at the end, drawing body contours without the aid of any primitive elements, or they hastily jot down the gesture lines and shapes without regard for proportion and perspective. Either way the result is unsatisfactory.
Carrying the metaphor, what I have seen anxious developers do is start with the far right drawing without any gesture lines. They task team members with drawing each limb separately and at a premature level of detail. When at last the team attempts to pin the components together the perspectives don’t match, the proportions are childish, and the result is hideously unusable. The irony is that — just as a rough pass of detail over an expertly-arranged set of gesture lines can yield a pleasantly unfinished portrait — a simple overlay of features and polish atop an expertly-ordered primitive architecture is the very definition of a minimally-viable product.
There’s another software development pitfall suggested by this metaphor. Accurate and pleasant gesture lines are extraordinarily difficult to master. They may look like stick figures to an untrained eye, but they’re anything but. Countless hours of practice and studious observation are required to become proficient at drawing these primitive shapes. If you undertake them without care, the resulting drawing will have all the same flaws as a drawing made without any gesture lines. In the same way, an architectural roadmap must be considered with extreme care. Don’t just list everything you know, list everything you don’t or can’t know. You don’t have to plan every detail, but you must wrestle with the problem area long enough to be reasonably confident that your architecture will be both efficient in the short term and stable for the medium term. If you’re lucky it will be stable for the long term. No matter what you choose, it’ll always be a guess. But make it a well-educated guess.
A Concrete Example
Here’s a concrete example of the kind of discussion I think can be spared some time at the beginning of a project without making commitments that over- or under- engineer things. Consider an app backed by a web service with user-specific accounts. Questions that might come up during a planning phase:
- How likely do we think it is that the app will ever need to support more than one account at a time?
- If we choose not to leave space for multiple accounts in our architecture, how disruptive would it be if multiple accounts suddenly became a requirement?
- How much additional up-front effort would it take to leave space for multiple accounts in our architecture though we would only ship with user-facing support for a single account?
- How likely is it that we’ll have to support iOS State Restoration, and would this be impacted by our chosen account plan?
- What else haven’t we considered, and is any of it risky enough to require addressing now?
And the key points during that discussion might be:
- We have no idea how likely it is we’ll need to support multiple accounts. All we know is it’s not currently required.
- If we think we’ll never have to support multiple accounts, one option is to provide global access to a singleton instance of an account.
- If we suddenly have to support multiple accounts and we’re using a singleton instance fixed to one account, that requirement change would be very painful to support.
- Passing an isolated account via dependency injection instead of providing a globally-accessible singleton instance would be comparatively easier to migrate to a multiple-account setup.
- Passing an isolated account via dependency injection would have a trivial impact on overall level of effort in a single-account application.
- Dependency injection could conceivably make supporting iOS State Restoration harder as that API is based on isolated view controllers re-instantiating themselves via NSCoding. Passing references to specific account instances during or after state restoration is considerably more complex than if restored view controllers had immediate access to a global instance during decoding.
Please note I’m not arguing for one way of the other here. I’m merely sketching out some terrain over which such a discussion might traverse.
Conclusion
In the end there’s always risk. You make the best choice you can given the information you have. I recommend discussing at length both the near and medium term before comitting to a near-term plan. All too often, these discussions either don’t happen or they happen in a rush and so risks aren’t considered to the full extent that it is possible to consider them given current knowledge.
That last line is the bad habit that rubs me wrong:
the risks aren’t considered to the full extent that it is possible to consider them given current knowledge.
This is the point of the quote from that ICU physician I admired so much. You always have more time than it seems like you do. You always have time to consider the impact of what you know and what you don’t, even if you choose not to address any of the risks up front, even if the outcome of that consideration means cutting huge corners. At least the risks you’re taking are calculated.