By Jonathan Crossland
https://github.com/JonathanCrossland/ammerse/wiki
https://substack.com/@jonathancrossland
Design is all about tradeoffs. Whether your software is built on grander architecture or it is a simple application, your decisions shape and form the software. The qualities of the system are embedded by you into code. How you did this, truly matters, because code is important. The journey from learning how to code, to managing a team of people with a large budget is a long difficult learning process. Designing software for next week is hard enough, but how do you design for the future? How do you think ahead and plan effectively?
Software has many qualities and the tradeoffs begin with the first line of code. Developers are making decisions with or without experience, with or without supervision, with or without an experienced architect. We are all designers and we all need to embody good design principles.
Over the years, many principles have become popular, like SOLID, or GRASP, but these speak to coding artefacts only. There has been SCRUM and the Agile movement, but these speak to team topology and process. AMMERSE is a bridge between process, thought, team roles and design. How do we design this? What did we design this for?
The principles can act as categories, weights or a design record. They categorise project artefacts and design principles, helping decision-making and improving your mental model of design and the relationships around it. You will learn how helpful these are soon enough, but let’s start with a basic introduction to each of the 7 principles.
AgileDesign: This is highly malleable code. The very best sort of design-time code changes and enhancements. Agile code obeys cohesion and coupling best practices, but it’s main objective is to keep nimble code. The weight is “How agile should this code be?” and the category includes design patterns which enable agile code, such as the TemplateMethod or Strategy Pattern.
MinimalDesign: A minimal design is fit for purpose. We obey heuristics such as “less is more”. The main purpose is to create a small elegant necessary abstraction to solve the problem. Minimal is not the absence of design, rather it is the succinctness of the design.
MaintainableDesign: Code that is easy to read and understand. Quick to debug, quick to change with certainty. Maintainable code has many facets and is not just neat code or nice partitioned, it’s everything from learning curve, prevention of brittleness and even how easy it is to debug.
EnvironmentalDesign: Fits into the world, in architecture, language, aesthetically and technically. Environmental is a system that behaves correctly according to the rules of the platform, coding standards to rules.
ReachableDesign: This is a design that fits within constraints such as a budget, timeline or features. We want a design that reaches the required constraints but also with time to spare or perhaps incremental releases.
SolvingDesign - A solving design not only solves a problem now, but can deal with a certain level of complexity and change, so that it can solve an extension of the problem at a future date. Solving doesn’t introduce new problems for which we solve which creates new problems. We must be careful to solve accurately and without creating new issues.
ExtensibleDesign - Run-time extensibility of the system provides us with the ability to solve problems later, without recompiling or deploying large parts of the system. Extensible design allows an ecosystem to develop around the code, an extension of the original.
Jonathan Crossland https://www.patreon.com/jonathancrossland