The art of coding

Today I spent few hours in my favourite London museum: The Design Museum.
I went to the main exhibition called Designer, Maker, User where they created a journey between these 3 actors explaining how they are linked together and all the innovations they brought up in the past 100 years in different industries like transportation, fashion, design and so on.

During the time spent in the museum I was able to create a parallelism between the exhibition topic and the software world.
I truly believe that we are creating some sort of art when we write code, if you want in an hidden way because our users can appreciate just the “visual” result more the journey behind it but in a certain way it’s what we are evaluating when we look at a statue or a painting right?

Communication

At the beginning of this journey there was a sign with the topic explanation:

Design is a process carried out by people, for people.
At its heart is a dialogue between three key people: the designer, the maker and the user.
[…] The exhibition shows how designers respond to the needs of makers and users, how users consume and influence design and how revolutions in technology and manufacturing transform our world

Does it sound familiar? Have you ever thought how many times we are executing this process on a daily basis in our job?
All the innovations we went trough in the past few years moving from procedural programming to functional programming, from MVC to Reactive architectures, from Monolith to Microservices architectures?

Have you ever realised how important is the feedback loop (dialogue between designer, maker and user) in our job too?
A feedback loop that is partially hidden behind techniques like unit testing, TDD, continuous integration or continuous delivery.
I saw several times in my career people integrating or using these techniques without understanding why they should do it.
The feedback loop is a well known technique in many Agile and Lean frameworks and you can learn about ita lot from different talks and books.
If you are curious how to improve it I’d suggest to start reading a book on Kaizen, you will discover the feedback loop as cornerstone for your continuous improvement journey.

Simplicity

Few steps later, I found a couple of subway maps: the first London Tube Map and the New York subway map.

the first Tube Map

Both were created around 70s with the main intent of simplify how to travel across the city.
Independently that these maps distort the reality not providing a perfect representation of the city, they become the standard for travelling for millions of users from all over the world.

The takeaway here is the simplicity: simplicity in our code, simplicity in our tests, simplicity in our architectures, simplicity in our daily tasks.

A technique that I learnt during my career is no matter how complex is a specific task or implementation, it can always be divided in smaller chunks of work and when you reach the smallest one, then you can start working on it.
This approach will give you 2 main benefits:

  1. you are defining a list of steps to follow in order to create a more complex algorithm, therefore you are already thinking how to achieve the final solution in a systematic way.
    I’d suggest you to write down the list of things to do so you can visually see what you need to achieve (what is not visualised, doesn’t exist)
  2. if you have a list of small tasks that you can achieve in minutes instead of hours your self awareness will grow minute by minute and at the end of the day you will see many things achieved instead “just a few” big tasks.

Modularisation

Another interesting video that I watched in the museum was related to the design of new Tube trains available in the future.
In this case the main goal for the designers would be increasing the frequency and the capacity of each line maintaining the same infrastructure.

new London Tube train

A part from the current infrastructure (tunnel size for instance) the designers need to take in consideration how often these trains will be replaced.
In fact each train will remain in use for 30–40 years and you can understand how many innovations and improvements the humans can do in this large amount of time.
So they approached the problem taking in consideration the 2 big constrains (time and infrastructure) and they designed a larger train optimising every single centimetre inside each coach, creating bigger entrances for speeding up the access inside the coach but, more importantly, for accommodating the future innovations that could improve their trains, they have created modular part inside each coach that could be removed and exchange with something better in the future.

That approach completely blew my mind, the modularisation of applications is a problem solved in many ways inside the software world.
Encouraging loosely coupled relations over tight coupled ones, is a cornerstone in all the main frameworks.
Think for a moment about the frontend framework evolution where, after React release, they moved all to a more component-oriented architecture.

Think then to all the design patterns that are encouraging decoupling objects since the beginning of the software history… it’s incredible how easily we can retrieve these important concepts of software engineering in the real world.

If we want to take a similar approach in an industry closer to the software one, let’s talk about the Fairphone 2 released in 2016.

Fairphone 2

Fairphone 2 is a modular phone that will guarantee the longevity of your device changing different parts on demand instead the entire phone.
The company made the modularisation a feature of the new device.
Totally a different approach taken by Apple with the iPhone for instance where replacing a part of the phone is (almost) impossible.

Every time you are thinking on a new or existing project, think about how to modularise it, how to break dependencies and improve your code.
In particular how the different modules are going to “stick” together.
Often we don’t spend much time on the “contracts” between systems, but it’s very important investing the right amount of time for creating the “perfect glue” for your application.
Think how much we have done in the bast moving from a monolithic architecture to microservices where communication, monitoring and logging are way more important of the code is running inside a microservice for instance.

Wrapping up

We are often very busy working with new libraries, frameworks and languages; anyway sometimes we will need to stop for few hours or even a day, looking around us and understand that probably the next innovation in the software industry could be “borrowed” by existing tools already available in the real world.

Leading Lean Software Development: book review

It’s a long time that I don’t share thoughts regarding a book that I’ve read, but this time it’s totally worth the effort to write down this blog post.
I used to read between 15 to 20 books per year during my commuting time and I really enjoy the different points of views of the authors and it’s fascinating how the same topic can be treated in so many ways.

Leading Lean Software Development

The book that caught my attention is called Leading Lean Software Development from Addison Wesley.
I read many books on Lean and Agile topics but this one, I’ve to say, it’s one of the best for people like me that works in software development with these methodologies.
I strongly believe that there isn’t a framework that could rule them all, so I love learn and try different approaches like Scrum, Kanban, Kaizen, Grows and many others outside there and catch the essence in order to use the best technique when I need it.

This book does exactly that, it’s not only emphasising the importance of Lean methodologies but it’s mixing Lean methodologies with software engineering practices and give many example how these techniques helped to succeed not only in the software industry but also in the “real world”.

The most stunning example is regarding how the Empire State Building was created in less than a year and how it’s possible to have the same efficiency in the software development!

There so many take aways inside Leading Lean Software Development book that it’s hard to share all of them, but I think it’s a great collection of my believes in the Lean and software development world.
For the first time I could say that I’m represented by a book!
It’s a MUST read book in my opinion and the most interesting part is that there is another book written by the same authors way more practical that I can’t wait to read: Implementing Lean Software Development.

I hope you’ll find the time to read them and if you want to share other books with great value just leave a comment