May 17, 2023
Barcelona’s Sagrada Familia is bathed in sunset light, and I’m watching the procession of colours. They find a place among the forest of columns. My dreamy thoughts are nowhere near my work.
But suddenly the colour show is over. I’m in a hurry to catch the last few minutes of the Sagrada Familia opening. The sudden jolt back to reality brings with it a realisation — the way in which the Sagrada Familia has been designed and built is so similar to the … journey of a product built in the Agile way.
It seems that the main secret of Gaudí’s success is his quest to emulate the organic motifs of nature. What surprises me is that the way he works, the creative quest he pursues, also follows an organic, empirical path. So far, this has proven to be the most efficient for the IT world as well. And what we are fortunate enough to see is that these principles are spreading to other areas, more and more actively every year.
So make yourself comfortable. Now it’s time to go into detail. Why is it that Gaudí could be considered as one of the first trainers of the Agile way of working?
How can you be sure that your project will work? Read a lot? Do lots of calculations? Gaudí’s approach proves that it’s not enough: the most important thing is to try and validate your ideas as soon as you see their potential. It’s easy to get caught up in a lot of guesswork and endless arguments: Will it work? What will go wrong? An expert in geometry, he wassuspicious of complex mathematical calculations and had a preference for empirical verification. He knew that heavy calculations and theoretical design only prolong unnecessary work. That’s what the empirical approach is all about.
Gaudí’s way of working is all about working empirically. Let me describe the general way he iterated, and you’ll see the similarity:
Do you see how many steps of validation he had? Each of them allowed him to improve his approach. He could also stop at any point if the idea did not work. Yes, he had to rebuild a lot, but what he ended up delivering was of a very high quality.
The same thing happens with an agile product: you build a working piece of code to validate that it meets a customer’s needs to a certain extent and that it’s technically feasible. Each iteration represents a higher level of mastery and is designed to serve its purpose more fully than the previous one. It’s all about prototyping, iterating and learning at every step.
Do you think Gaudí had any idea what the Sagrada would look like when his successors finished it? My guess would be that he had a general idea, but of course he could never have had any idea of the tiny details, such as, for example, a Japanese artist’s placement of all those elaborate beetle sculptures on his temple doors. It’s really impressive that so many people were able to contribute to the cathedral after Gaudí’s death, without changing the general motifs. You can’t underestimate the importance of creating favourable conditions for other people to continue his work.
If you compare the architecture of a software product with the architecture of a building, it’s often said that the architecture of a building should be thought through from start to finish, otherwise it will be extremely difficult, if not impossible, to extend it. This seems to contradict what we learned about the Sagrada Familia just now. Unfortunately, having this work done exclusively by software architects — has been preferred and is still widely practised. Some architects are clever enough to involve developers closely in the development of the architecture, but many are trapped in a silo, trying to solve the problem without being involved enough in it.
Of course, I can’t help but agree that if you’re building conventional houses one after the other, there’s no point in experimenting with the architecture. Let’s face it, it would even be stupid to do so (see Cynefin framework). But when we’re talking about building new products, where we have a high degree of uncertainty, where we can completely change the ultimate business value that we’re trying to achieve, that’s not the way we do it. One day Facebook was a local university collaboration tool, Zoom was a pure conferencing tool, and look where they are now. It’s all about teamwork: every developer is responsible for the product architecture because they’re producing the code. It’s their responsibility to make it agile and flexible and to adapt it to the needs of the moment. It’s extremely important to make it so that every time you add a new piece, it’s not the constraints of the architecture that dictate your functionality, but the objective reality.
The impressions are overwhelming: the ornate lines of the cathedral columns with their dull, dynamic tones intertwine with the colourful lines of code in my colleagues’ favourite editor. It is difficult to concentrate, the mind jumps from one thought to another — we need a break. We sit down on the bench for a moment and take a deep breath. Let’s take some time to digest these impressions and meet again in the second part of this series to be inspired by the genius of the Catalan architect.
