Tag: Architect

97 Things Every Software Architect Should Know – 25/97

Scope refers to a project’s size. How much time, effort, and resources? What functionality at what level of quality? How difficult to deliver? How much risk? What constraints exist? The answers define a project’s scope. Software architects love the challenge of big, complicated projects. The potential rewards can even tempt people to artificially expand a project‘s scope to increase its apparent importance. Expanding scope is the enemy of success because the probability of failure grows faster than expected. Doubling a project‘s scope often increases its probability of failure by an order of magnitude.

Why does it work this way? Consider some examples:

• Intuition tells us to double our time or resources to do twice as much work. History[1] says impacts are not as linear as intuition suggests. For example, a four person team will expend more than twice the communication effort as a team of two.
• Estimation is far from an exact science. Who hasn‘t seen features that were much harder to implement than expected?

Of course, some projects aren‘t worth doing without some built-in size and complexity. While a text editor without the ability to enter text might be easy to build, it wouldn‘t be a text editor. So, what strategies can help to reduce or manage scope in real-world projects?

• Understand the real needs – The capabilities a project must deliver are a set of requirements. Requirements define functionality or qualities of functionality. Question any requirements not explained in terms of measurable value to the customer. If it has no effect on the company‘s bottom line, why is it a requirement?
• Divide and conquer – Look for opportunities to divide up the work into smaller independent chunks. It is easier to manage several small independent projects than one large project with interdependent parts.
• Prioritize – The world of business changes rapidly. Large projects‘ requirements change many times before they‘re completed. Important requirements usually remain important as the business changes while others change or even evaporate. Prioritization lets you deliver the most important requirements first.
• Deliver results as soon as possible – Few people know what they want before they have it. A famous cartoon shows the evolution of a project to build a child‘s swing based on what the customer said and what various roles in the project understood. The complicated result only faintly resembles a swing. The last panel, titled ?What would have worked?, shows a simple swing using an old tire. When the customer has something to try, the solution may be simpler than expected. Building the most important things first gets you the most important feedback early, when you need it most.

Agile advocates[2] exhort us to build “The simplest thing that could possibly work”. Complex architectures fail far more often than simpler architectures. Reducing project scope often results in a simpler architecture. Scope reduction is one of the most effective strategies an architect can apply to improve the odds of success.

97 Things Every Software Architect Should Know – 24/97

Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind you’re more likely to be stuck with it, so that incidental decisions become significant and the softness of the software is reduced.

One of the simplest and most constructive definitions of architecture comes from Grady Booch: “All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” What follows from this is that an effective architecture is one that generally reduces the significance of design decisions. An ineffective architecture will amplify significance.

When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes “How do I design so that the choice between A and B is less significant?” The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B (and that the appropriate choice is not necessarily obvious or stable).

An architect may need to go in circles before becoming dizzy and recognizing the dichotomy. Standing at whiteboard (energetically) debating options with a colleague? Umming and ahhing in front of some code, deadlocked over whether to try one implementation or another? When a new requirement or a clarification of a requirement has cast doubt on the wisdom of a current implementation, that’s uncertainty. Respond by figuring out what separation or encapsulation would isolate that decision from the code that ultimately depends on it. Without this sensibility the alternative response is often rambling code that, like a nervous interviewee, babbles away trying to compensate for uncertainty with a multitude of speculative and general options. Or, where a response is made with arbitrary but unjustified confidence, a wrong turn is taken at speed and without looking back.

There is often pressure to make a decision for decision’s sake. This is where options thinking can help. Where there is uncertainty over different paths a system’s development might take, make the decision not to make a decision. Defer the actual decision until a decision can be made more responsibly, based on actual knowledge, but not so late that it is not possible to take advantage of the knowledge.

Architecture and process are interwoven, which is a key reason that architects should favor development lifecycles and architectural approaches that are empirical and elicit feedback, using uncertainty constructively to divide up both the system and the schedule.