Not long ago, I came upon a LinkedIn post. It's in French, but the theme is about sharing risk between the customer and the contractor in software development projects. To sum it up, the author is advocating for the Agile way: fixed-price contracting puts risk on the shoulders of the contractor, while time-and-material gives responsibility to the customer.

Some commenters showed surprised that we, software developers, are not able to precisely assess risks by ourselves. They compare software development to the industry of house building: if house builders are able to estimate, why can't we? I see that comparison a lot, and it's getting a bit old, so I'd like to share my opinion once and for all.

First, let's talk about the elephant in the room. The often-seen comparison is with car manufacturing. This cliché is much easier to discard. Manufacturing applies to factory-like processes, with an industrialized assembly line: software development obviously doesn't fit this picture.

Comparison with house building, on the opposite, is much more subtle. House building is "obviously" not an industrial process. This shows a lack of understanding about the different kinds of houses available.

Imagine you want to buy a new house, but your finances are pretty constrained. You meet with a house manufacturer. Its catalog offers several houses, which fit both your requirements and your budget. You choose one, pay the required sum, wait the agreed-upon time for the workers to build the house - done.

An unknown fact is that the low price of such houses comes from a deeply optimized cost. This include the price of materials. Moreover, factories manufacture components, for examples windows; their size follows a standard; etc. High volumes also allow to bring down the costs. Eventually, the building itself is just a straightforward assembly of the components.

All in all, this specific house building process is entirely industrial. That's the reason why costs - and delay - can be precisely evaluated beforehand. And that's what people's expectations are about software development. On the other side, they just conveniently forget the part about the catalog. This is not software development, but buying off-the-shelf software.

When one installs off-the-shelf software, it needs to be configuration. Yet, it's not enough for some (most?) customers, as the configured software doesn't meet the customer's requirements. There might be a couple of reasons for that:

• The configuration might be "for real"
• Users cannot cope with changing their business processes, because of the organization's lack of change management
• etc.

The real reason is irrelevant.

With some luck, changes can be part of existing extensions (or plugins). To make a parallel with house building, one might want a fancy bathtub. This is still choosing on a catalog, but with a small degree of customization. In both case, it just requires a minimal amount of manual work. This still is within the bounds of an industrialized process.

When configuration customization goes beyond those bounds, a lot more work is necessary. In software, a development team needs to change the acquired software: this becomes a full-blown project. Readers who have been part of such projects know that the cost - and the delay - are quite like custom software development projects: uncertainty rules. Of course, it depends on the exact scope of the planned changes.

The last category is comprised of architect houses. A customer of such house needs to define everything by himself, with the help of the architect of course: the materials, the design, and all fancy details - I love overflowing swimming pool myself. In this context, while the team might have built parts of this specific building before, most parts probably have not. Moreover, the assembly of all those parts is unique. That's the reason why the customer is paying actually. This entails risk. For that reason, the provider will probably ask for a huge margin, to cover those risks.

In IT, this maps to what custom software development is: chances are the team never created something similar before. Yet, software development has other risks. Civil engineering has more than 5,000 years of history. The laws of physics didn't change much in that time span. Some might argue that new materials appear on a regular basis. But it takes time to integrate them in the house building process at an acceptable cost.

On the other side, software development is barely 70 years old. We are working with cutting-edge technologies. Worse, once one has built the foundations of a house, the customer can see them. He understands the quantity of work that's already been put in the construction site, and the consequences of changing his requirements.

But our job is to deal with abstractions, entirely in our head. Developers understand how hard it would be to change the existing code base, others... not that much.

I hope that after reading this post, it becomes evident why the house building parallel comes short. Basic house building is a factory process, which supports no customization. The deeper the customization, the higher the risks. And software development projects are highly different from one another. If it already exists, you'd better choose Buy over Build.

Originally published at A Java Geek on September 6^th, 2020