AMMERSE mnemonic acronym for thinking and acting on quality in design and coding teams. AMMERSE is a design language and design repository enabling better communication and intent of good designs.

1. Introduction to AMMERSE
Jonathan Crossland
Semantal Institute
jonathancrossland@gmail.com
@jcrossland

2. AMMERSE
WHY quality?
WHY should we code better?
WHY should we design better?
WHY should we refactor better?
WHY should we iterate better?
WHY should we make better software
experiences?

3. The case for quality
 ROI will increase
 Working with complexity in a quality
environment costs less than dealing with
complexity in a 'no quality' environment
 Reactive is more expensive than proactive
 Overall satisfaction guaranteed
 You will feel better
 Your customers will love it more

4. But many things are subjective
What is good design?
How do you improve your design?
How do you know when its better?
How do you communicate design intention?
How do you improve your code?
How do combine all the advice out there?

5. How do you design for change?
How do you trust your team more?
How does design fit into proceses?
What is does minimal mean?
Does KISS or DRY still apply?
How does cohesion fit with my tooling?

6. Experience
 GOOD experience is valuable
 Experience is hard to quantify
 Some experience is subjective
 When we manage to communicate experience
in words, we can spread it
 Context of experience and applicability is also a
form of experience
 Some are intuitively brilliant, their experience
comes to the surface

7.  Digesting experience and embodying it can be
hard
 We are creatures of habit and we work in
typically very narrow experiences
 We need to collate experiences into our own
mindset and benefit from it where possible

8. Examples of Experience
 DRY, Dont Repeat Yourself (Andy Hunt and
Dave Thomas)
 KISS, Keep it stupid simple (Kelly Johnson)
 Code to abstractions not concretions,
dependency inversion (Robert C. Martin)
 Convention over configuration (David
Heinemeier Hansson)
 Domain-driven design (Eric Evans)

9. Step 1
 Categorize the experiences
 We can now understand the category of the advice
 We can go to a category and get a subset of
applicable advice

10. Step 2
Weight the experiences
 We can apply weights on the applicability of the
experience
 We can choose how much of that experience we
want to use in a given context

11. AMMERSE
Mmemonic for 7 Categories
Agile
Minimal
Maintainable
Environmental
Reachable
Solving
Extensible

12. AMMERSE
4 Cornerstones (MVP)
Agile
Minimal
Maintainable
Environmental
Reachable
Solving
Extensible

13. AMMERSE
Contraints
Agile + Extensible <> Minimal + Maintainable +
Environmental + Reachable + Solving
Solving + Minimal + Reachable > Agile
Reachable = Solving + Extensible

14. Basic Weights
Project A
Agile (0)
Minimal (0)
Maintainable (0)
Environmental (5)
Reachable (5)
Solving (5)
Extensible (0)
Project B
Agile (5)
Minimal (5)
Maintainable (3)
Environmental (5)
Reachable (3)
Solving (5)
Extensible (5)

15. Project A) Agile (0) Minimal (0) Maintainable (0) Environmental (5) Reachable (5) Solving (5) Extensible (0)
Project B) Agile (5) Minimal (5) Maintainable (3) Environmental (5) Reachable (3) Solving (5) Extensible (5)
Project A has Environmental considerations, a
tight deadline which must be Reached to Solve
the requirements
There is NO emphasis on Agile, Extensible or
Maintainable

16. Project A) Agile (0) Minimal (0) Maintainable (0) Environmental (5) Reachable (5) Solving (3) Extensible (0)
Project B) Agile (5) Minimal (5) Maintainable (3) Environmental (5) Reachable (3) Solving (5) Extensible (5)
Project B has Environmental considerations, a
deadline which should be Reached to Solve for
now and potentially future problems by providing
an Agile and Extensible solution to the
requirements
There is a strong emphasis on agility and
extensibility of the design to solve problems later

17. Design Language
Build a login system with
Agile (2), Minimal (5), Extensible (0)
A login that has some flexibility, but not overkill at this stage, keep it
simple and need,ready to be extended in code if need be.
Build a login system with
Extensible (5)
We want complete flexibility with plug-in like extensibility.
This is going to be a large part of our business.

18. Design Repository
Agile
Strategy Design Pattern, Observer, … , ...
Extensible
Microkernel, Adaptor, Documentation, ... , ...

19. Step 3
Create a map of where things are preferred in a life-cycle

20. Design phases

21. AgileDesign
is to alleviate the stress of change.
MinimalDesign
is a design that is small, efficient and elegant.
MaintainableDesign
is an easily maintainable design and implementation.
EnvironmentalDesign
is to be friendly to the environment, not pollute.
ReachableDesign
must be reachable, attainable goal.
SolvingDesign
must solve the problems it set out to solve.
ExtensibleDesign
is to allow extensibility to solve other problems later.

22. Whats next?
Now learn how to apply AMMERSE to
Architecture | Design Decisions | ChangePotential | Modeling | Process