SolvingDesign

"must solve the problems it set out to solve."

"The best way to escape from a problem is to solve it." - Brendan Francis

It must be a SolvingDesign, and not introduce new problems. It should also try to be a long lasting solve.

A Solving Design:
  • Solves the initial problems.
  • Does not introduce new problems.
  • Should not envelope the problem so tightly that it cannot be agile enough to solve future ones.
  • Solves problems from multiple, but hopefully all angles or entry points.
  • Is a long-lasting solve.




Intent

The Intent of SolvingDesign is getting the problem solved. A design does not have to "complete", fully abstracted, large or all encompassing to be solving. Sometimes a problem can be solved with very little design.



Motivation

Sometimes design becomes design for the sake of designing. A lot of code becomes large with too many abstractions, or generalizations that surpass the needs. We need to be able to solve the problem, first. Sometimes developers fix problems that have nothing to do with the original problem at all. This can happen quite easily, and should be avoided as far as possible.



Solution

Design with RechableDesign, and get the solve done as early as possible. The first iteration, if possible, should already have the solve in place. Whenever, the code increases, make sure the original solve works for the original problem. This can be done with Unit Tests and code review, but never just code review.

Applicable Patterns

Sprints (SCRUM)
Burn Down (SCRUM)
Pair Programming (XP)
Feedback (XP)
Courage (XP)
Communication (XP)
ReachableDesign (AMMERSE)
Develop Overall Model (FDD)
Build Feature List (FDD)
Design By Feature (FDD)



Compliments
ReachableDesign


Ammerse Principles