Part two: The years 2004 … 2016
Ever been confronted with name-dropping while being on a programming related discussion? This two-part series on Citations one should have heard of brings some light into the depth of name-dropping and why the background behind those terms helps you getting a better programmer. I arranged the bits and pieces in a chronological order at best knowledge. You find the first part of this series in Part 1 of my blog-post.
2004 - Strangler application
2005 - Ports and Adapters architecture
2005 - SOLID
2005 - Poe's law
2006 - Viscosity
2014 - Microservice prerequisites
2016 - SISO
2004 - Strangler application (Martin Folwer)
As Martin Folwer
brought it to the point: The programs we code today are the legacy codes of tomorrow.
“…Let’s face it, all we are doing is writing tomorrow’s legacy software today…” (see Strangler Application)
Provide means in your software systems
for other future software systems
to strangle it. The strangler application
will do so when time has come to replace your (then legacy) software systems
. Using an event
driven interceptor pattern
seems to be a promising approach for this undertaking, as this enables you in the future to easily hook and intercept into your software systems
(event interception
).
What do we learn from this?
At least I learned that I should use something like the
refcodes-eventbus
or therefcodes-interceptor
for future application decease by strangulation!
2005 - Ports and Adapters architecture (Alistair Cockburn)
Think different! Instead of making your adapters
to take over the protocol
of some third-party software systems
, make your microservices
define what they expect form their adapters
! Get independent from third-party software systems
!
That is the way the Ports and Adapters architecture
makes you approach your software design
. Alistair Cockburn
initially called it Hexagonal architecture
and had the following intend in mind:
“… Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases …” (see Hexagonal architecture)
What do we learn from this?
This is a very useful approach to tackle your
software design
when building yourmicroservices
.
2005 - The SOLID principle (Uncle Bob)
Robert Cecil Martin
, also known as Uncle Bob
, named the so called “first five principles” in his essay on Principles of OOD SOLID
, which is an acronym and stands for:
S
: Single responsibility principleO
: Open/closed principleL
: Liskov substitution principleI
: Interface segregation principleD
: Dependency inversion principle
“… The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time …” (see SOLID)
Uncle Bob
initiated the development of the Agile Manifesto and he is a leading member of the Software Craftsmanship movement which is dedicated to Clean Code software engineering.
What do we learn from this?
Create a cool new acronym by mixing lots of existing ideas together! Make sure it ends up with a solid name.
2005 - Poe’s law (Nathan Poe )
Ever said or wrote something meant to be sarcasm or parody and someone took you verbatim word-for-word? In case this hit you on the internet when posting something, then you ran into Poe's law
, stating that when you do not tag your <sarcasm>
statement</sarcasm>
(e.g. using the ⸮
punctuation) as being irony or the like, eventually someone will misunderstand you, be it because of stupidity or be it by intend. In case of the latter, some troll is to degrade you and your credibility, in both cases you may look like an idiot.
What do we learn from this?
Be cautious, in everyday work situations (e.g. drinking coffee with your "colleagues") you quite often will encounter stupid individuals using
Poe's law
as a career strategy to make themselves look clever by making clever you look stupid.
2006 - Viscosity in programming
“… In object oriented programming, viscosity refers to the ease at which a developer can add design-preserving code to a system. …” (see Viscosity)
High viscosity
: If it is easier to add a hack than it is to add code that fits into the design → Considered badLow viscosity
: If it is easy to add new code to the program while maintaining the design → Considered good
What do we learn from this?
Taking a look at how
software systems
evolved over the years, it seems that code heroes likehigh viscosity
even though thesoftware systems
may be of an excellentlow viscosity
.
2014 - Microservice prerequisites (Martin Folwer)
Are you tall enough?
You are proud, from a coding perspective, your fancy Spring boot
, Node.js
or Docker
based application is ready to go live, it runs like a charm and passed all unit tests
on your local machine. Having some microservices
implemented and up-and-running is just half the way you have to go for satisfactory operating
herds of microservices
.
What happens when you operate
ten microservices
each on ten nodes
?
- Ten
deployments
for tenmicroservices
on tennodes
makes 100deployments
… - Ten
configurations
for tenmicroservices
on tennodes
makes 100configurations
… - Ten
logfiles
for tenmicroservices
on tennodes
makes 100logfiles
… - Ten
microservices
on tennodes
to bemonitored
makes 100microservices
to bemonitored
…
All this is to be maintained by your system administrators
, poor guys! And this throughout all your environments, from local development
followed by something like testing
and ending up in production
?
Get lost or get it automated!
In his article Microservice prerequisites
, Martin Folwer
proposes you to have …
- Rapid provisioning
- Basic Monitoring
- Rapid application deployment
… in order to be tall enough for microservices
.
What do we learn from this?
Sometimes size matters, even in a
microservices
driven world!
2016 - SISO principle (Siegfried Steiner)
This is a variant of the IPO model
with regards to the FIFO
principle. The SISO
principle is based on the observation that the lower the input quality for a given matter, the lower the output quality becomes. It was first mentioned in 2016 by Siegfried Steiner
on his blog post Better programs: Citations one should have heard of (part 2):
SISO
is an acronym and stands for:
S
: Shit (moving targets)I
: In (from management or sales)S
: Shit (bad outcome)O
: Out (for the stakeholders)
The SISO
(shit-in-shit-out
) principle is very generic and can be applied to a software development process as well as to strange everyday common live situations. It stands in strict contrast to the processes of alchemy
.
Do not confuse it with the GIGO
principle as the GIGO
principle can easily be avoided by choosing a dedicated exceptional execution path upon garbage in
instead of just producing garbage out
(see also exceptional execution path
in this blog).
The SISO
principle can be summarized as:
SHIT
→ INPUT
→ PROCESSING
→ OUTPUT
→ SHIT
It is a proven fact that the SISO
principle cannot be avoided in cases where you as a technician can be overruled by management or sales. In theory, the SISO
principle can only be avoided in case you as a technician have strong opinion amplifiers such as bouncers or doorkeepers at hands.
What do we learn from this?
As we all know: "Shit happens". If you don't start
SOLID
right from the beginning, you will end up with an unfriendly result.
Flash back
The years 1957 … 1999 are approached in Part 1 of this article series:
1957 - Arithmetic IF
1960 - KISS
1968 - Conway's law
1972 - Encapsulation
1973 - Actor model
1979 - Cohesion
1980 - Call by value-result
1981 - ACID
1983 - Real Programmers
1983 - Our rich neighbour Xerox
1983 - The Spirit of C, Guiding Principles
1987 - Law of Demeter
1998 - CAP
1999 - DRY