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.
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
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.
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