Making reasonable architectural decisions

The Problem

Let’s think about what could happen when you take two developers, and lock them up in a room until they have a consensus on what is the best programming language they should pick up for the next project.

From my experience that could end up not so nice. Without getting deeper into how they would look like after 10 hours, I would bet they will not find consensus in quite many cases. We guess that the reason is, that they will likely argue more preference-based which will turn out to get personal pretty fast.

Read this to know why we think so.

So we want to provide our members with principles that guide them through a smooth decision-making process, with the best result for Dancier.

The Principles

Id	Name	Description
AP1	Low Coupling	Strive for low coupling between distinct modules, where dependencies on each other are minimized.
AP2	High Cohesion	Let all parts with strong relations towards each other belong in the same module (function, class, package, deployable,…)
AP3	Keep it simple stupid (KISS)	Based on our interpretation of Agile Development we think that we should choose the simplest approach to tackle a task. Particularly, we always try to avoid optimizing things before it turns out that optimization is needed (see Donald Knuth). This applies, in the same way, to small things eg. optimizing algorithms like SQL queries choosing frameworks for persistence, offering rest endpoints, frontend frameworks infrastructural topics like VCS build system As well as it applies to "bigger" things eg. Deciding architectural things like using CQRS Using microservices vs. putting things into a monolith
AP4	Favor what is proven	Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that: we are getting more support from other developers if we run into problems expect more support from the upstream project itself, and also the project itself will exist for a longer time have better tooling support (if applicable) have it easier to find more developers
AP5	Go deep not wide	Before thinking about introducing the 4th other database, think again: do the benefits justify the introduced increased complexity of being able to understand and operate now 4 different database systems?
AP6	Principle of Least Surprise	Build software and design the architecture such that it doesn’t surprise users or fellow developers. When making decisions, prioritize predictability and ease of use over cleverness and novelty. This general principle can be applied to many aspects, such as making architectural decisions as well as building a clear UI for the end user.
AP7	Delay Design Decisions	Delay design decisions until they are necessary. Decisions should be made at the last responsible moment, fostering a culture of experimentation. This will gather new insights that can be used to iteratively design the architecture. No point in designing and implementing capabilities upfront may never be used - it is a waste of time and resources.
AP8	Match techniques with skills of core team members	The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it.

Name

Description

AP1

Low Coupling

Strive for low coupling between distinct modules, where dependencies on each other are minimized.

AP2

High Cohesion

Let all parts with strong relations towards each other belong in the same module (function, class, package, deployable,…)

AP3

Keep it simple stupid (KISS)

Based on our interpretation of Agile Development we think that we should choose the simplest approach to tackle a task.

Particularly, we always try to avoid optimizing things before it turns out that optimization is needed (see Donald Knuth). This applies, in the same way, to small things eg.

optimizing algorithms like SQL queries
choosing frameworks for persistence, offering rest endpoints, frontend frameworks
infrastructural topics like VCS build system

As well as it applies to "bigger" things eg.

Deciding architectural things like using CQRS
Using microservices vs. putting things into a monolith

AP4

Favor what is proven

Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that:

we are getting more support from other developers if we run into problems
expect more support from the upstream project itself, and also the project itself will exist for a longer time
have better tooling support (if applicable)
have it easier to find more developers

AP5

Go deep not wide

Before thinking about introducing the 4th other database, think again: do the benefits justify the introduced increased complexity of being able to understand and operate now 4 different database systems?

AP6

Principle of Least Surprise

Build software and design the architecture such that it doesn’t surprise users or fellow developers. When making decisions, prioritize predictability and ease of use over cleverness and novelty. This general principle can be applied to many aspects, such as making architectural decisions as well as building a clear UI for the end user.

AP7

Delay Design Decisions

Delay design decisions until they are necessary. Decisions should be made at the last responsible moment, fostering a culture of experimentation. This will gather new insights that can be used to iteratively design the architecture. No point in designing and implementing capabilities upfront may never be used - it is a waste of time and resources.

AP8

Match techniques with skills of core team members

The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it.