Developer, the modern architect and general contractor

This is an archive of blog post I wrote during my second venture (Sybil).

Building a new digital house🔗

Developing a new software is like building a new house. You design an ideal plan in your head. The plan consists in realizing a purpose, where each part has its role to play. You even think about it in an aesthetic way. You see its inherent beauty because it fulfills its purpose in a genuine and simple approach that makes totally sense. But when you start to implement it, realize it, build it, the reality punches you back without any warning. Welcome into the real world.

The analogy is very interesting, in my opinion, because it helps non-developers understand why it is so difficult to anticipate the difficulties of implementation. A little disclaimer before I'll develop it. I'm not an architect or general contractor myself. It's then only my personal view. But in a way, it serves my argument because it's very close to a common point of view of the job.

The architect's plan🔗

An architect should imagine an use of the available space to serve some purpose and by respecting some constraints. Outside money consideration, the available space is defined by the terrain where you can build the house or the building, and the technology that you can use to delimit that volume above this terrain (or below).

Those constructions could have different purposes. It could be a familial house, an open space dedicated to offices of an IT company, a shop, a factory, etc. But this is still a very general purpose, when you go in details, it is split itself in different parts with different goals. Together they form the whole.

The constraints are the money, the technology, the available materials, the availability of skilled workers, the time, the imagination of the architect, and the capacity of the customer to express what he wants (in other words, the capacity of the architect to help the customer to express what he wants).

A plan is not the reality🔗

Even if the architect has a great experience of the implementation of his plans, even if he knows the kind of difficulties to face, he cannot totally anticipate the very tiny details that depend on other persons or the environment. Even if he can go really far in the details of the building such as considering the dimensions of hollow core slabs, he cannot be sure that at the time of building, they'll be still valid for any reasons (the workers don't place correctly them, the provider has changed them, the engineer has calculated that it's not enough solid). He cannot really manage the whole complexities of the system without building it. He has to be realistic and design a house or whatever the building is in a reasonable time that answers the needs or asks of his customer. He has to understand that the plan won't be exactly implemented as he has drawn it. A plan is just a plan. Its goal is to find a good arrangement of rooms according their functions and the will of the customer. Add the tastes above ... and you can understand it's not an easy exercise.

The surprises of the reality🔗

After different variations and iterations, a final plan is achieved, the construction can start, and the real problems can begin.

The realization will be lead by a general contractor and his workers. Maybe some sole proprietorships has to be involved. The materials will be provided by a lot of different providers depending on their nature, the taste of the architect and the customer. The weather could enter in the game. The neighborhood. The city. A provider could do bankrupt, and you have to find another one. This is no more in the mind of one or a few architects. It is in the hands of several dozens of people that have to interact together. Worse, the customer can finally and really understand what the architect has drawn for him, and don't like it …

Where the analogy stops🔗

I think in a way, it's totally the same in software development. At the design stage, you have a general purpose incarnated as the application. The application is formed by different features and functionalities. You have constraints, technological ones, money, time, available skilled people.

The designer cannot go very far into the details because it cannot really manage the whole complexities of the system without building it. The reasons are numerous. It could be a question of tools, developers, statement of the problem, team management, available expertise, unknown or hidden technological challenge, etc. At the end, you have to build it to face the problems ... and maybe review or change the plan. You can even do it several times. It's not unfeasible, it's even become a mainstream way to develop software: iterate often, stay agile.

This is the biggest difference between those two worlds. The analogy stops there. Software is a virtual world where you have more flexibility. It's easier to unmake or destroy than in the real world. This is an opportunity in terms of productivity and development process that the architect and the general contractor cannot benefit. Imagine if we could apply agile methodology to construction, we could build a first very simple 0.1 version of the house … in two weeks. You can show it to the user, he can experience it, and give you feedback if it corresponds to his needs. You can test some ideas and see if they really work. You will face the problems very early and understand what does it mean in terms of implementation challenge. From those learnings, you can iterate and build a next version … in two another weeks. And test it again.

This is the true power of software development, you can build the software and design it nearly in the same time. It gives you in flexibility. Besides, it helps you to really realize what your idea means in terms of real code source to write and run. This is a real opportunity. As software developer, we should take advantage from this difference and not waste it.

If you have any comment, question, or feedback, please share them with me.

Subscribe to the blog!