Programming, between puzzle and Lego

Paul Stanescu
4 min readNov 20, 2018

Whatever we do, most of the time, we are trying to find a corespondent in real life. Sometimes, maybe, we are thinking that this might be wrong, but is not, in the end we are humans and we are living in this life, let’s not over complicate it with unnecessary thoughts. A programmer concept said “Keep It Stupid Simple”, apply it in the real life every day and the happiness will be the output :).


Above I mentioned the “corespondent in the real life”. Starting from this point, I will make a link to the puzzle, but I will refer only the puzzle’s border. Most of us we are starting the game trying to build the borders to be able, further, to go to the next step, to build the actual content.

Why we are stating from them?

First we need to have a clear overview about what we want to build and the borders are the constraints. Placing the constraints first, will make it easier to find the correct place for each pieces and achieving the goal.

How does it work on programming?

Every new project that we are building, it’s trying to solve, at least, one real life problem. In order to solve it, before starting to write code, we are starting with a rigorous analysis. We are identifying the keywords, possible problems, possible solutions, opportunities to use some technology and so on. In the end, the outcome will be a strategy which will be estimated in effort and time.

If we are thinking back to the puzzle, we will see that we are doing, mostly, the same things: we have to know how many pieces we have, how complex the picture is, how big the size of the picture will be, in order to be able to start using a right table. Knowing the number of pieces and analyse the complexity of the picture, identifying the areas when the colors are quite similar we will be able to estimate the effort and the time to solve it.


Starting to create the border represents defining the architecture used in the project, technology and tools. In the end, all of these will define the borders of the project and the coder that will be write later, will be attached to this skeleton. The code used to build the borders is one of the most important part of the project, because it will say the direction, the way used to implement features. These system’s capabilities, aggregated, which will solve the target problem in the end.

During borders’ creation is important to use only pieces which are easily connected, even if this means to iterate through other many solutions that will not be used in the project. Trying to force using some elements that are not possible to be fully integrated within project, sooner or later will lead to fissures and it will be very hard or even impossible to fix them properly. Changing the component, you will have the chance to affect the project stability. The research part, that you made in order to make the best decisions, will be helpful to better understand the needs and also the know some alternatives if something is changed or is going wrong.


Having the borders in place we are ready to solve the puzzle, but the content of the puzzle (what is in between the borders) will not be a puzzle anymore, will rather Lego pieces.

Playing with Lego we have to combine different pieces in order to build the model. Having this goal, we are using using big pieces, small pieces, pre-build pieces like wheels, figurines and other things.

In programming the pieces are classes, modules, services and these can have different sizes based on what they have to do and the pre-build components are found on libraries that we are using to build the solution. Like Lego pieces, also the classes and modules should have a singe responsibility, to used it rightly and to understand exactly where should be used.

A solution has multiple components respecting a predefined structure, design, like Lego pieces. These component are very well integrated together creating a robust and stable system. Every component is tested individual to ensure a very good quality.


Lego should fit the puzzle’s borders and every time we should respect the order: first create the borders and only after that create the content. Creating the content and only after that placing the borders, will most probably lead to a successful failure. Why? Because you will not be able to fully test the whole functionality with automated tests, the design will not be defined for specific components and when changing a component, the borders will be changed as well.

Having a good design means taking in consideration the future growth, eliminating the impact, high cohesion and low coupling.

Just code it!