26 March 2019
Is software development like construction? I've done both and here's the whole truth
It’s been one year since we’ve managed to complete the renovation of our new office at the Old Post Office in Gliwice. Now, we’re fully settled in our new HQ and I think it’s a good time for me, as the CTO, to take a step back and answer this popular question – ”is software development like construction?”
The last twelve months were really busy but also rewarding for us. Our headquarters received a variety of prestigious awards for its interior design. We’ve been appreciated by CBRE with the Office Superstar award for the best office in the IT industry in Poland, we won the Architecture XXL voting and we’ve been mentioned by the Polish edition of Elle – to name a few.
These distinctions are great indeed. However, the process of renovation was a tiring work. Coordinating it was not only a demanding task for me but also a valuable lesson. That’s why I’ve decided to share some insight with you. I think it’s a perfect time to rewind and take a closer look at the whole process of construction and renovation itself.
Some people say that software development is like construction. To heck with “some people” – when I talk to a non-technical client, it happens that I use this comparison myself. 😉
For example, you can compare a framework to a solid basement. Or backend to the “invisible” parts of the house (foundations) which are extremely important for the final building (frontend). And so on. But is it accurate? Being the CTO of the software development company and having dozens of projects completed, makes me feel confident to try and compare the area of my expertise with the construction project I had a chance to coordinate.
It was my first construction project of this size, so I was not only a client, a novice but also a non-technical partner who knows nothing about this particular “technology” (i.e. construction industry). It was a valuable experience for me, as normally I stand on the other side of a relation between a builder (developer) and a client. During the construction process, I had to coordinate the work of 11 working crews managed by 11 supervisors who had to arrange and renovate around 1600 m2 of the office space. I was really curious if you can easily compare these two industries. Below, I’ll try to present its similarities and differences I’ve noticed during the construction process. Also, I’ve pointed out some of the conclusions I’ve come up with.
1. Just like in software development, initial questions in construction are: “how much is it?” and “when can I expect the results?”. And just like in software development – it’s difficult to estimate total expenses.
2. When you need to develop an app, there are many possible solutions – exactly as when you build a house. Also, even if you have an exact specification (which is even more precise in the construction industry), there is still a lot of questions which appear during the development.
3. You shouldn’t save on quality – whether you need to build a house or develop an app – quality is the key. The truth is that low costs = poor quality in both software development and construction industry.
4. In both industries, there are some specific, internal processes. In construction, there are design, ventilation, sewage system, plasters, paintings and finishing – processes which need to come one after another but also mesh with each other and sometimes need to be repeated. Doesn’t it sound like the iterative model in IT?
5. Both in IT and in construction, there’s a strong division into two groups: technical and non-technical people. The first ones use a complicated jargon and look down on the second ones who don’t understand a single word. For example – do you know what veneering is? It’s simply about arranging two surfaces in one line. I’ve heard this term multiple times before I learned (from context!) its meaning. Using jargon by developers in IT looks exactly the same for a non-technical person.
6. Another similarity is the commonness of misunderstandings. Even though you’ve signed piles of documentation files and agreements, there’s always a person who works on a particular part of the project and complains that wasn’t informed clearly enough about how to do something, making lots of excuses. On the other hand, if something is not agreed in a straightforward way, the same person will simply choose the easiest way to do it.
7. Aesthetics – or rather the lack of them. For any technical person (in both construction and software development industries) they are in the background. For example, our “green wall” in the dining room is covered with reindeer lichen (very nice-looking and quite useful kind-of-moss thingy) and during the construction work, it turned out that in the middle of this wall there need to be two huge ventilation grills. Obviously we didn’t want them to be on that wall as they would destroy the whole visual effect, however, the workers were more than surprised – they only thought about the functionality, not about the aesthetics. On the other hand, in both industries there are people who care about the final, visual effect. That’s why both industries need technicians and designers.
8. In both construction and software development costs never grow in a linear way which means that for twice as much money you wouldn’t get the twice as good product. At some point, you have to spend a lot to get just the slightly better thing, but that’s the cost of being the best.
9. Both industries are full of invisible yet essential things (like backend in IT or sewage system in a building) that usually cost you more than you expect (especially that you simply don’t understand them).
10. I thought that software developers are the “masters of excuses” but actually builders are even better. Well, it seems that in all industries, all delays or mistakes are explained with a variety of prepared, sophisticated excuses. Or the fault is blamed on someone else.
11. Many things look way more complicated than they are and… conversely. Some elements of construction look difficult to be changed but, in fact, sometimes it’s relatively easy. For example, I thought that moving a wall a few centimeters further is a huge problem. It turned out that it’s easier than, let’s say, rearranging wires in the same wall. Very similar surprises await you in the software development.
12. Finally, I found out that, in construction, there’s something called a “framework”! It means nothing more but using different elements of interior finish which fit each other (have a matching colour, shape etc.).
1. The final price in the construction industry is a component of two elements: the cost of materials and labor. at The Software House (and in a variety of other software development companies based mostly on FOSS) it’s almost only about the labor.
2. When talking about the material costs: it’s way easier to explain why it’s worth paying more for high-quality floor tiles than trying to justify the price of something as “abstract” as the better quality code. At least to non-technical clients.
3. Crew members change very often in the construction industry and pretty rare in software development (at least in responsible software houses). It’s mainly because of the domain knowledge and difficulty in replacing a developer.
4. A vital part of the construction industry is the presence of a variety of subcontractors and it’s a substantial difference comparing to the software development. It’s caused by the industry specificity – you need electricians, plasterers, sewer workers, plumbers, fitters and so on. And when you develop a piece of software, normally there’s only one contractor – the software house that you outsource to. Of course, software houses also cooperate with some trusted vendors supplying them with the additional workforce, but usually, it’s a deeply internal process that is transparent to the customer.
5. In the construction industry, it’s easier to speed up the work by increasing the number of workers. In IT, it won’t help – or even could make things worse.
6. Some issues seem to be difficult to solve or change in the construction industry without putting the money on the table, as the construction industry is way more budget-focused than the IT industry. In software development, at the estimation stage, you agree on the price, but you also indicate that the final expenses may vary depending on the development. In the construction industry, you get the exact estimation and a construction plan beforehand and it’s difficult to perform any changes during the construction process unless you mention that you’re willing to pay more.
7. Some things during the building process cannot be changed as, for example, they need to meet fire protection standards. In IT almost everything can be changed (but sometimes it requires more time).
8. Durability – in software development, it’s way easier to develop a product which will work forever. In construction, it’s different – you must consider a variety of factors (and spend lots of money) before you decide on a solution that won’t break down easily.
Conclusions, or lessons I’ve learned
Well, the construction of our new headquarter was definitely a valuable lesson for me. Performing the role of the client in a huge project helped me putting myself in the position of our partners and understanding them better. What are the most important lessons I’ve learned?
1. First days are the most important. I remember how lost I felt at the beginning. I didn’t know what should I do and what will happen next. I think that both in software and in construction projects it’s important to have a guide – someone who can help you understand all the processes.
2. I had to trust a lot of people (in fact, I had no other choice). And, while I wanted the trust to be maintained, I lost it very quickly. The best examples of trust test are deadlines – if someone promises to finish a piece of work on Friday and it’s not even close to being done on the next Monday, your level of trust naturally drops down. This is why I never make promises to my clients if I’m not 100% sure that something is doable.
3. You need to be careful about what you agree on. Sometimes, you can instinctively agree on some solution just because you believe that the person who presents the idea is a professionalist who won’t harm you. Unfortunately, it may happen that your partner offers the easiest – and sometimes a useless – solution.
4. Therefore, if you want your client to make a crucial choice you should describe each option and their consequences – to make sure that your client’s decision is well-considered and not random.
5. Also, you should be able to provide a regular update on progress. Nothing is more frustrating than a situation when you can’t see any progress in the project. Even if progress is slow, it’s worth showing any new element.
It’s time to answer the initial question. Is software development like construction? Well, you’ve probably already realised that it’s difficult to give a definite answer. You can point out some similarities but, at the same time, there are a lot of differences between software development and the construction industry. However, for me as the CTO of a pretty big software house, one thing is most important: you can really learn a lot when you decide to change a seat and become a client. Such a shift of perspective can definitely improve the way you look at your own clients in the future.