SolvingDesign is principle 6 for AMMERSE. SolvingDesign explores the entire scope of a solution to problems. What are your requirements, what do you need to code?

1. AMMERSE - SolvingDesign
Jonathan Crossland
Semantal Institute
jonathancrossland@gmail.com
@jcrossland

2. Principle 6 - SolvingDesign
"... must solve the problems it set out to solve"
“The best way to escape from a problem is to
solve it” - Brendan Francis

3. Issues with Solving
 We create solutions that create problems
 We solve problems for now
 We under-solve problems
 We solve problems for later not now
 We solve problems awkwardly
 We solve non problems
 We solve problems that later expand
 We solve problems that later dissapear

4. Quality Solving is
 Solve for now and make a gain on tomorrow
 Solve with consistency
 Solve with robustness
 Solve with efficiency
 Solve with elegance
 Solve completely

5. Conflicts / Constraints
 Time
 Complexity of the problem
 Lack of Experience
 Lack of Domain Knowledge
 Confusion on requirements
 Incorrect understanding of the problem
 Overkilling the solution

6. Solving completely (ish)
By mixing AgileDesign and ExtensibleDesign with
SolvingDesign, we can begin to solve tomorrow's problems
or allow easier solving later.

7. Solving completely (ish)
Preparing the design for later, by simply leaving the room to
grow and introducing Minimal concepts and abstractions.
Avoid constraining the code with specific naming, types and
interfaces.
Example: favour lists of, even if you have instruction that its
only one. Vehicle.Drivers – not Vehicle.Driver

8. Solving completely (ish)
Depend on abstractions not concretions.
Is there ChangePotential?
Evaluate and deal with what may change now, before the
code gets more complicated and difficult.
But use wisely in pressing areas (where change would be
imminent and close), as overuse can lead to overkill.

9. Solving completely (ish)
Check ReachableDesign and MinimalDesign to constrain
your efforts. You can defer solving problems to a later date.
With an eye on what is pragmatic.

10. Solving completely (ish)
Separation of Concerns, High Cohesion, Single
Responsibility, DeCoupling are a few principles that would
apply here.
These are AgileDesign principles.
Check your project iteration constraints and see how much
AgileDesign will be neccesary.

11. Solving Clues
Favour doing something for
If the business requirements changed subtly, how would it
affect the code?
OVER
If the business requirements changed significantly, as in
changed to a new industry/domain, what percentage of the
code would be still usable with no change?

12. Other Solving considerations
Ask a team member if something is necessary.
Ask if a particular aspect of the requirement could change
soon, later, ever, not likely?
Is the problem is too large to solve completely?
How core is this feature to the system?

13. Want to learn more?
And yes there is lots more..
I run courses on AMMERSE, for which this is just 1 of 7
principles.