Contribution 33

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
(Try before choosing)
Line 1: Line 1:
== Try before choosing ==
== Try before choosing ==
-
[early draft of the concept; compete, observe, choose]
+
Creating an application requires many decisions to me made. Some might involve choosing a framework or library while others centre around the use of specific design patterns. In either case the responsibility generally lies with the architect on the team. A stereotypical architect might gather all the information that can be gathered, then mull over it for a while, and finally decree the solution from the ivory tower. Not surprisingly there is a better way.
-
Let's assume we delay important technical to the last responsible moment [is this maybe another point for this list?], how do you make the decision? A stereotypical architect might gather all the information, then mull over it for a while, and finally decree the solution from the ivory tower.
+
In their work on lean approaches Mary and Tom Poppendieck describe a technique for making decisions. They argue that we should delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. This is prudent because the later a decision is made the more information is available on which to base the decision. However, in many cases more information is not the same as enough information, and we also know that the best decisions are made in hindsight. What does this mean for the good architect?
 +
 +
The architect should constantly be on the look out for decisions that will have to be made soon. Provided the team has more than a handful of developers and practices collective code ownership the architect can, when such a decision point approaches, ask several developers to come up with a solution to the problem and go with it for a while. As the last responsible moment arrives the team gets together and assesses the benefits and drawbacks of the different soutions. Usually, now with the benefit of hindsight, the best solution to the problem is apparent to everybody. The architect does not have to make the decision, he or she merely orchestrates the decision making process.
 +
 +
This approach works for small decisions as well as for large ones. It can allow a team to figure out whether or not to use the Hibernate templates provided by the Spring framework but it can equally well answer the question which JavaScript framework to use.
-
Our new and modern architect, when he has a suitably large team, asks a few team member to solve the problem, then let's them work with it for a while, and finally gets everyone together and pick the best solution.
+
Of course, trying out two or even more approaches to the same problem requires more effort than making a decision upfront and then just implementing one. However, chances are that an upfront decision leads to a solution that is later recognised to be sub-optimal, leaving the architect with a dilemma: either the team rolls back the current implementation or they live with the consequences, both of which result in wasted effort. Even worse, it is entirely possible that nobody on the team recognises that the approach chosen is not the best one, in which case effort is wasted without any chance of addressing the waste. After all, trying multiple approaches might be the least expensive option.

Revision as of 08:03, 10 July 2008

Try before choosing

Creating an application requires many decisions to me made. Some might involve choosing a framework or library while others centre around the use of specific design patterns. In either case the responsibility generally lies with the architect on the team. A stereotypical architect might gather all the information that can be gathered, then mull over it for a while, and finally decree the solution from the ivory tower. Not surprisingly there is a better way.

In their work on lean approaches Mary and Tom Poppendieck describe a technique for making decisions. They argue that we should delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. This is prudent because the later a decision is made the more information is available on which to base the decision. However, in many cases more information is not the same as enough information, and we also know that the best decisions are made in hindsight. What does this mean for the good architect?

The architect should constantly be on the look out for decisions that will have to be made soon. Provided the team has more than a handful of developers and practices collective code ownership the architect can, when such a decision point approaches, ask several developers to come up with a solution to the problem and go with it for a while. As the last responsible moment arrives the team gets together and assesses the benefits and drawbacks of the different soutions. Usually, now with the benefit of hindsight, the best solution to the problem is apparent to everybody. The architect does not have to make the decision, he or she merely orchestrates the decision making process.

This approach works for small decisions as well as for large ones. It can allow a team to figure out whether or not to use the Hibernate templates provided by the Spring framework but it can equally well answer the question which JavaScript framework to use.

Of course, trying out two or even more approaches to the same problem requires more effort than making a decision upfront and then just implementing one. However, chances are that an upfront decision leads to a solution that is later recognised to be sub-optimal, leaving the architect with a dilemma: either the team rolls back the current implementation or they live with the consequences, both of which result in wasted effort. Even worse, it is entirely possible that nobody on the team recognises that the approach chosen is not the best one, in which case effort is wasted without any chance of addressing the waste. After all, trying multiple approaches might be the least expensive option.


By Erik Doernenburg

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools