Better programs - Citations one should have heard of (part 2)

Better programs - Citations one should have heard of (part 2)

Siegfried Steiner
Siegfried Steiner
6 min read

Categories

Tags

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 the refcodes-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 your microservices.

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:

“… 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 bad
  • Low 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 like high viscosity even though the software systems may be of an excellent low 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?

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 …

  1. Rapid provisioning
  2. Basic Monitoring
  3. 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

LinkedIn Reddit