Few words on the 4th element of Simple Design

The 4 elements of Simple Design

Suggestions to young men

Few days ago I made an interview.
The interviewer (Tommaso Torti) asked me if I have suggestions to give to young men starting a new career in software development.
Just as a recap, I mentioned:

  • find a company with high skilled software developers
  • changing job frequently: for example every 2 years
  • after few experiences, remain a little bit longer (5 years?) to find how good your design decisions have been in the long term
  • read classics: not only about software design… I mean also The Mythical Man-Month by Fred Brooks, Peopleware by Tom DeMarco, etc…

A missing point

But I forgot to mention one of the most important point.
In my opinion, to become a real expert in Software Development (not only OOP), you have to spend a lot of time on the 4th element of Simple Design: minimal methods, classes and modules (also known as “fewest elements”).

I know it sounds silly: “ehi man, I am already writing the minimal methods, classes and modules!”
Maybe! But, maybe not!
How do I know?
2 reasons:

  1. I have seen code written by lots of people. Expert people. Very often, I could have written the same code with half of the objects/methods/modules maintaining (or even increasing) the readability of the entire code base
  2. I found people able to write the same code I wrote, with a reduced number of objects/methods/etc…

So yes, it is a virtuous “mechanism” that once established creates an “obsessive” research on “how to write less, keeping high readability”.

What happens in reality is that, Object Oriented Programmers are focused mainly on SOLID principles, on the first 3 elements of Simple Design and don’t give any attention to reduce the things they write.
This is the reason I wanted to say few words on the 4th element.

A story

I have a story to share with you.
In my company, we had a coding exercise as an entry test for every applicant: Sales Taxes (you can find my solution at that link).
As an interviewer, I have seen lots of solutions and I can tell you that the majority of applicants created a solution with more than 30 objects. Some of them, reached more than 50 objects. I remember one guy proposing a solution with more than 80 objects.
Few people used 10 objects or less.
I haven’t seen all solutions, so I am talking just about what I have seen.

Another aspect: some developers wrote a solution with lots of objects that could adhere perfectly to SOLID principles and to the first 3 elements of Simple Design. Other developers wrote with fewer elements, but with procedural code.
I can tell you this: I accepted solutions wrote by the latter more often than by the former.
The reason is that, it is very difficult to train yourself on writing less. I think it is almost impossible to train on production software without a mentor helping you, unless you are naturally “obsessed” on this topic.

It is all about “simplicity”

There is another reason I think the 4th element is important.
If you are an object oriented programmer, you are naturally inclined to organize “things” (objects, methods, etc…).
But, as mentioned in The Laws of Simplicity by John Maeda, there are a lot of other ways to create simplicity and the first one is called “REDUCE”.

How to improve

Assuming that you want to train yourself anyway without a mentor, I can share some “exercises” you can do in your daily job or in some pet project you have:

  • try to start with just one module: you can add more modules later. If you really need them (and probably they will be created with a different idea behind them)
  • try not to duplicate your domain objects due to your adapters.
    For example when you have a domain object and then you have another DTO for the REST adapter, one for the persistence, another one to call your supplier, etc…
    If you really need this solution, try to avoid at least a hierarchy of mappers to create those objects from domain ones and vice versa: put factory methods in those objects instead
    Anyway, did you try with just data mappers and Maps? Sometimes, the idea that you need another object lies only in your mind…
    Did you try using reflection with some project convention?
  • try to count the objects (or methods) you are creating for a new feature.
    Put a label near each one: NEEDED, MAYBE, USELESS
    – USELESS: you should delete them immediately
    – MAYBE: “maybe” you can do something to make them USELESS
    – NEEDED: maybe you can think again… once more… are you sure? If you really think they are NEEDED, leave them alone
  • avoid “extract method” to have then just a private method containing one call to a collaborator. It does not increase readability at all! Change the name of your collaborator instead (or of the method name called)
  • pay attention to Parameter Objects. The idea that you need a Parameter Object when you have more than n parameters is the most stupid thing I have ever read (if you think this call discount(Product, Price, MarketStrategy, Report) is less readable than discount(DiscountRequest) you’ll be in trouble reading my blog). Besides, Parameter Objects often hide domain objects in the primitives used (I wrote a story about this: check Once upon a time… in Objectsland).

If you want to share another training exercise, please write a comment below.

I hope you’ll find interesting to spend some time on this aspect of software design.

Once upon a time… in Objectsland

where only objects with a meaning are admitted

"Spiral Jetty" by Robert Smithson
“Spiral Jetty” by Robert Smithson

Once upon a time, there was a place called Objectsland.
Every day, objects were living their life, working together, forming new collaborations.
The city was continuosly growing and flurishing.

One day, Necromancer Techcoacho Ignoranto arrived in the city.
He had to deal with all the objects in the city.
Soon, he became scared. He didn’t want to deal with so intelligent objects.
He’d have want objects without a brain, so that he could control them.
The other objects would have not left him doing that, so, one night, he decided to cast a spell mentioned in ancient books of refactoring: “Parameter Objectorum!!!”

The day after, Objectsland seemed as before, but after few weeks new objects arrived… they were like buckets of texts, numbers, … and they were a lot… they were: the Parameter Objects! uhuhohohahahahahahah

One day, one of this Parameter Object was filled with a text girl called Airline and a boy called Flightnumber.
Airline was in love with Flightnumber, but she was just a lonely text and he was just… a number (e.g. 89)? or a text (e.g. “0089”)? he didn’t know…

Since the arrive of all those Parameter Objects, the life in Objectsland became difficult. You had to deal always with them for everything and they were so many that you didn’t know who was in charge of something.

One day, a mage arrived in Objectsland. He was called Oldoop Pragmatico.
Looking at the poor Airline walking alone far from Flightnumber, he decided to step in! Immediately, he cast the powerful spell: “Ubique Dominatum!!!”

Since then, no one has seen a Parameter Object.
Eventually, Airline married Flightnumber and they decided to form a family: they called themself FlightDesignator following the suggestion of IATA Guild.

All the free objects decided to put a signboard at the entrance of the city.
This is the message:

Welcome to Objectslands where only objects with a meaning are admitted.
For data buckets, DTOs, etc… please follow the other street.
It will lead you to Wasteland

A note for Software Engineers:
yes, I’m arguing that ParameterObject is an antipattern that will get you to MagicContainer sooner or later.
It’s just a matter of time.

I have been interviewed

I have been interviewed the past Friday (2020-07-17) by Tommaso Torti.
You can see it at this link. Unfortunately it is in italian, so…

The title could be translated to “Inside the mind of a team leader”.
I talk about my experience as a team leader in a period starting from 2015 to 2019 (I’m not a team leader at the moment due to management decisions), but I touch experiences I had as a technical leader, software developer, etc… in my whole career.

I hope you’ll enjoy it.

The most important convention lies in your build system

The conversation

rick: “OK, good, it seems the build is successful! So we can create the merge request and eventually release the software in production!”
john: “No, wait… you need to push on git and then wait for the pipeline on Gitlab”
rick: “oh ok. Let’s push the changes. (wait some minutes for the pipeline). OK, the pipeline is ok… so now we create the merge request!”
john: “Yes sure… (after some time for the code review)… “
rick: “OK the branch has been merged, so now I think we can release it”
john: “No, wait… maybe we should get a feedback in our QA environment”
rick: “oh why? don’t we have already a green build?”
john: “well yes, but it doesn’t test everything”
rick: “oh OK… yes… it happens sometimes… let’s make this manual test… (after dozens and dozens of minutes). OK, it seems working. Now we can release it!”
john: “oh nooooo!”
rick: “what’s happened?”
john: “the step after the deploy in our QA env failed!”
rick: “and?”
john: “they are our ‘api-tests'”
rick: “what do they do? a sort of end to end tests?”
john: “no, we call “end to end test” tests that involve all services. These ‘api-tests’ are run just against this service”
rick: “oh ok, but why are we running them now and not with our build system?”
john: “because they are slow”
rick: “mhm… whatever… where can I find them?”
john: “they are in the same project. There is a specific directory for them”
rick: “so they are in the same project but we do not run them in our build system, right?”
john: “yes, because they are slow”
rick: “yeah I get it”
john: “anyway you can run them manually… you have just to run in IntelliJ xyz and then you can open that folder and run in IntelliJ xyz”
rick: “yeah… manually… of course… ok 😕 let’s see why they are failing, right?”
john: “oh I found! the data they are based on are no more available… we have to find some others…”
rick: “sorry, are they based on data coming from other systems?”
john: “yes”
rick: “so if someone touches those systems and those data, our api-tests fail miserably, right?”
john: “yes”
rick: “and we need to check the error, find new data allowing them to pass and update them, right?”
john: “yes”
rick: “OK, it’s 6.00 PM… and I’m tired… can we fix this tomorrow?

Feelings, agreements, time

There are a lot of things happening in this conversation.
If you look at the feelings of rick and john, it seems clear that while both started with high energy and passion, rick‘s feelings are degenerating… but why? Even john‘s feeling are not so good when api-tests fail, but not for the rest of the conversation.
If you look at what they are discussing, it seems like rick was expecting something from the build system… but what is that?
If you look at the conversation itself, you can imagine that it required some time… but they were just finishing a feature, weren’t they?
What’s your opinion about this conversation?
Do you feel more near to rick or to john?

Rick is right

Rick is right.
How do I know that?
Because Rick is asking just one simple thing: reduce cognitive load needed in this project to understand that something can be delivered in production.

We all have our tools: make, ant, maven, gradle, npm, …
We all have our commands, “phases” or tasks.
But what is missing here is the most simple convention you need in your build system: when you run the default command of your build system and it is green, the software can be released in production.

Let’s imagine if you have dozens and dozens of projects: do you feel comfortable in reading dozens and dozens of docs (maybe the RELEASE chapter in your README.md) in order to understand how to make a release? do you think it’d be simple to follow dozens and dozens of checklists with different steps between each other on how to be sure your software is working as expected?

What about John?

I don’t know John.
But what I think is that John focused mainly on the software strictly related to the product forgetting that as an engineer/software-developer all processes and tools used during development phases of that software need the same care.
In this specific case, it seems the release process of that software have been left undone… as a checklist… maybe to be memorized and to teach to new colleagues…
Such a waste of time!


“Yes, you’re right! But in my company we have XYZ so this cannot be done”

I won’t answer to one of my colleagues in this way, but because this is my blog, I can be totally direct (and probably a little bit rude):
This is just an excuse.
I know that you are an engineer, my dear reader.
And as an engineer, you know that there is “very often” a solution to everything (yeah “always” can be too much sometimes).

Focus on the outcome: how simple would be releasing your project with such a convention in place?

A (Debian) Linux TTY console that rocks!

No i3 or awesome here!
Just a fuck**** TTY console (oh well in a VBox :D)

It is a little bit tricky ’cause (I think) nowadays there’s no much people tweaking this aspect. I found a lot of posts suggesting how to do that using grub. The problem is: now we have grub 2 and it works in a different way.

So how have I obtained this tty?

First of all pay attention, ’cause I have done this on a Debian. I don’t know how it can be done in others Linux distributions, just because (as you can see later), I have used a Debian specific utility to configure the console font.

Configure grub 2

Open grub 2 configuration file:

  sudo vi /etc/default/grub

and set the following rows:


then run:

  sudo update-grub2

then reboot your system.

Change console font

Here I’ve used dpkg-reconfigure that is an utility provided by Debian.

So run:

  sudo dpkg-reconfigure console-setup

and then I selected:

  . Combined - Latin etc... Greek
  6x12 (framebuffer only)

I think you have to reboot again… or maybe no… well if it doesn’t work immediately, try a reboot 😀

Why I wrote this post after so many years?
I’ll think about this in the next days and I’ll let you know in a couple of years 😀

3 things to remember when you play with MS Word docs in Java

I’m playing with my maven plugin (https://github.com/sixro/vodafonecanvassrelease-maven-plugin) and I need to insert texts in a MS Word document. Unfortunately there are some pitfalls you have to know if you use the Apache POI Java library. Continue reading 3 things to remember when you play with MS Word docs in Java