Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Technique 3: Change the Old Questions
Early in a project's life, a lot of the questions asked by architects are along these lines: "What will we use to do this?" or "How will we solve this problem?" These questions are important, but they aren't the most important questions, and they usually aren't asked at the right time. The beginning of a development effort is the absolute worst possible time to lock in a particular implementation or technology decision. Agile software developers have known this rule for years.
For example, if you're building your application on top of a database platform, the question "Do we use Oracle or SQL Server?" has huge consequences because the answer is so limiting (see Figure 5). Each technology has strengths and weaknesses that must be compared in the context of long-term use.
)
Figure 5 A question as old as time itself.
People don't often consider the more subtle limitation imposed by that question: That kind of database choice limits the number of options that will ever be considered. If you're making an expensive, in-depth decision now, it probably won't include the minor players today, and it certainly won't include options that emerge tomorrow.
However, if you're driving the establishment of a culture of encapsulation and ensuring that every decision comes with a built-in failsafe you can use to change that decision later, you don't need to make an expensive decision. If switching between one database platform and another is "just work" as opposed to "invasive surgery," the cost of being wrong goes way down.
This reasoning allows you to change the nature of the question, from "Do we support Oracle or SQL Server?" to "Which database back-end do we want to support first?" (see Figure 6).
Notice how powerful a statement that question makes. It simultaneously builds on and reinforces the ability to change your mind about decisions. It also opens up a world of options—without imposing restrictions on what those options are.
)
Figure 6 The real question.
Maybe the winds will shift later, and you'll want to change the database you support. Maybe a division will form in your market, and you'll need to support more than one database. Maybe an amazing new technology will emerge that obviates the need for any other database platform. In my experience, leaving your plans open to all such paths is unlikely to be harmful, and it frequently yields dividends.
This same line of reasoning applies to implementation decisions about the code your team is writing. You have to choose a way to solve a problem—there's no way around that. However, once you're ensuring that you can change your mind, the decision isn't as important, because no commitment is attached.
It's okay to try an algorithm you think might be slow but cheaper to implement. If your guess turns out to be right, you can try another one later at little cost.
So stop asking "Which of these technologies will we use?" or "How will we solve this problem?" and start asking "Which of these technologies will we use first?" or "How will we solve this problem for now?" (see Figure 7).
)
Figure 7 Another change to the process.