Thoughtful Reactions To Minimal Design Up Front

From ThoughtfulReactionsToXp:

Doesn't encourage experience to play a significant role in design. Design Patterns are all about leveraging others' experience.

That's right. Sometimes you just know there are no mines in a field, at other times you know there are. A design isn't just for programmers: it's like a vision statement. There is business value in being able to say where you heading, both for you and your customer. Up-front design can help you do this. Are there risks involved? Certainly. Does this mean up-front design must always be characterized as being risky? Certainly not.

How does minimal design up front affect experience? I would see the opposite, up front design tends to minimize experience and replace it with reliance on "do it the way we told you to do it."

The relationship between up-front design and experience seems to be quite straight-forward: if I have more experience I can plan more work, in more detail and with more confidence.

For whom would you be "planning" the work? If it is for yourself, why bother? If it is for someone else who is experienced, it would seem the planning is not encouraging the other person to use his experience. It is only if you are planning for someone who lacks experience that value may be received. It still seems that up front design is based on the assumption of lack of experience.

Planning and design are not about one person telling another what to do. Among other things design is about communication, about feeling sure people are headed in the same direction. It can be used to motivate people and capture the interest of talented designers and influential people.

Minimal Up Front Design ... Precludes synergistic participation of team members in design.

PairProgramming means that you get an extremely synergistic participation of all team members in the design. --LanceWalton

Or rather synergistic participation of two team members in any part of the design.

no, pairs keep changing therefore the ideas spread to other members rapidly.

How to prevent a closed architecture that is not flexible to change when you do minimal UFD? Constantly refactoring the architecture can be very costly.

See ThoughtfulReactionsRefactorMercilessly. See also UnwarrantedAssumption?

One of the risks of minimal up front design is how to answer the questions, "How much staff is needed?" "What development environment and what development skills are needed?" and "When do we start seeing results?" These questions often have to be answered as part of the initial justification of a project and often some commitments have to be made to various parties to get them to buy into a project (we'll provide XXX for the accounting department by YYYY).

Do you get more accurate answers by sitting back and thinking about it, or by starting and measuring it? Assuming equivalent investment in each activity

If I implement a single story and get some initial performance measurements I learn nothing of the future unless I start thinking and extrapolate from those results. On the other hand I can do a thousand thought experiments, either based on past experience or even pure speculation, and come to firm conclusions. Asking which is more accurate, thinking or measuring, is misleading. One is never much good without the other and the question of accuracy is one among many. We may, for example, want to narrow down the solution space without trying every solution.

To try to give you the answer I think you were fishing for: there are some considerations that are, in a sense, better made up-front. Scalability, for instance. It makes no sense to say that scalability can be easily refactored into a product without knowing what kind of scalability we are talking about. Do I mean scalability according to the amount of users, data, transactions or am I talking about the size and topology of a network or database? How will these affect my product in terms of third party licenses, installation and user training? Does my team have the competence to handle what is coming? You see design is not just about planning programming tasks; it's also about being prepared.

No, you can't predict the future. But that doesn't mean that you are confined to live in the present. Your customers will have plans and hopes for the future. You can lend your skills, technical knowledge and experience to help them paint that picture. Saying that to do so would be "bad practice" is just rhetorical nonsense.

Who will do the work to be measured? Where does the staff come from? To initiate a project, in any environment I am familiar with, I need to provide a projection of how many people I will need and what skills will be required. In return for being given people and the money to pay for them, I need to commit to provide some benefit within some time frame. Think of this as the PlanningGame in the large, starting with a short user story of great underlying complexity. Just as for individual user stories, the question is asked, "If I want X, what will it cost in terms of manpower, cost, and schedule?" Just as in the planning game, I must reply with a prediction of unknown accuracy, but as honest as I can provide. The difference is in the scale of the cycle; a budget cycle often runs in increments of 1 year as opposed of a development iteration of 1 - 3 weeks. In both cases, adjustments can be made mid-cycle, but it is far more difficult than to adjust between cycles. In both cases, it is a business decision whether to go forward with a user story or a project; a project, however, requires more planning effort due to the larger scales.