We define an architecture style as the structure of how the user interface and backend source code are organised, and how that source code interacts with a datastore; it describes a named relationship of components (topology) covering a variety of architecture characteristics.
Architecture quantum, on the other side, is the minimum architectural entity, and provides the scope for architecture characteristics. It is an independently deployable artefact (includes all the necessary components to function independently from other parts of the architecture) with high functional cohesion (one purpose) and synchronous connascence (implies synchronous calls).
A habit is a behaviour that has been repeated enough times to become automatic. The ultimate purpose of habits is to solve the problems of life with as little energy and effort as possible. An atomic habit is a little habit that is part of a larger system and it is a building block of remarkable results. The upside of habits is that we can do things without thinking, but the downside is that we stop paying attention to little errors, so remain conscious of your performance over time through reflection and review.
Small changes often appear to make no…
Architecture consists of the structure (the type of architecture styles used in the system: microservices, microkernel, etc.) combined with architecture characteristics (the “-ilities” that the system must support: availability, scalability, etc.), architecture decisions (the constraints of the system: what is and what isn’t allowed), and design principles (guidelines rather than a hard-and-fast rule).
Most of the following leadership principles, learned by Navy SEALs leaders, have proved to be universal, applicable and effective on every discipline. Each principle is supported by real stories of war.
Take ownership. Acknowledge mistakes and admit failures; accept blame foisted on your team, but pass on any praise.
When a friendly fire incident occurred, considered one of the deadliest sins committed by a SEAL commander, the author took the blame for everything that happened, since he was the leading commander, calming the troops’ anxiety and earning respect among others.
Remove any excuses for not accepting full responsibility for your…
Before getting into some kind of recap of Andy & Dave’s advices on “The Pragmatic Programmer” (advices I fully agree with), I would like to make the following disclaimer:
True pragmatic engineers know that there is not only one “right way” to do things, and that the “right way” depends fully on the given context (resources available, cost, time, etc.). That said, the following tips won’t be applicable in all circumstances 🤓
Build easy to change solutions because there are no “final” decisions.
Designing loosely coupled (orthogonal) systems make them easier to work with, to test, and to change, because…
Despite the example I’m going to share with you it is a simplified component of a very little service, the basic concepts are aplicable in general on most scenarios, as the conclusions at the end.
We wanted to create a simple processor that, given a message from a queue, extracted and pushed useful data to another service. The queue had different types of messages published by our development tool (called Jarvis), on each relevant step of the development process (as component creation, build, deployment, release, etc.). …
DDD is a set of tools that assist you in designing and implementing software. When you doubt that design matters, remember Steve Job’s insights: “Most people make the mistake of thinking design is what it looks like […] It’s not just what it looks like and feels like. Design is how it works”.
Without a proper design, developers may end up adding business logic in user interface components or persistence operations in the middle of business logic, building strongly coupled components. In addition, as they probably collaborate poorly with the business, they don’t give proper emphasis to naming objects and…
After some tests in which people scored very badly (even worse than chimpanzee would have done, choosing randomly responses), the author got to the conclusion that only actively wrong knowledge could lead us to answers like that (not missing knowledge).
People have an old dated worldview, to the time when their teachers had left school, but that is not the only problem going on, as they misinterpret the facts even when they are right there in front. This happens probably because our brains often jump to swift conclusions without much thinking (which used to help us to avoid immediate dangers…
There have been many attempts to measure the performance of software teams. For measuring the delivery performance, this research decided to focus on the following four measures:
Measures of software delivery performance tempo
Measures of stability/quality of the systems
Have regular non-update one-on-one meetings
Avoid information starvation
Achieve a good mix between incrementalists and completionists
Take care of free electrons
Be a nerd and protect the zone
Detect boredom and act
Avoid the Fez guy
Trust your twinge
Mandate when necessary
Organize off-sites to defeat the status quo
Maintain an engineering mindset
Take time to think
Soak to solve problems
Start your impossible task
Manage the disaster when the sky falls
Be prepared for reorgs
Be good at leaving
Collective chatter is part of the daily regimen of a healthy business, but this chatter will bury the…