Ammerse - SolvingDesign Introduction
- 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.