Blog

It’s Not Like Construction!

17 August 2020 | by Gauvain | 0 Comments |

0 Likes

It’s Not Like Construction!

Too many executives, both technical and non-technical, still generally think about the physical construction analogy when starting a custom software project. This because they’re both building things. And they both involve planning, quality checks, and rapidly improving technologies.

There are similarities, but no, building a bridge is a different thing than building a custom software application. Let’s get this straight!

Building a Bridge, Building Custom Software: The Similarities

First, let’s have a look at the similarities between the two industries.

1. Both are solving a problem. We need space for our employees, so we build a new office. We want to keep track of our expenses, so we create a new application.

2. The further you get in the project, the more expensive mistakes become. Each line of code in software and each part added to the bridge adds complexity.

3. Both need a great team working together to accomplish the task.

4. Process & project management – at their core is a process, and while the domain is different, the process shares common artifacts and rituals.

5. Developers hate bugs; builders hate defects. Nevertheless, they exist and have to be dealt with.

Why We Can’t Compare Software Building to Construction

Even with these similarities, how comes, we can’t compare how construction happens with the way software is built?

1. A construction yard builds a physical thing. From day one, you see the complexity growing the building or bridge arise. Software is a virtual product; you only see a small part of the complexity. It’s easier to see the value of your investment in front of a building than when you look at a simple and clean UI hiding the algorithms from the user.

2. A construction project is all about the deployment of scarce and valuable resources; materials, plants, and labor. Software development only requires talented people, creativity, and a laptop. It’s easier to calculate costs upfront dealing with resources than dealing with the skills of people.

3. Building a house is a ‘waterfall’ process. First, you build the foundations, then the walls and the roof. You move to the next phase when the first is done. Software is modular; you make several parts separately and glue them together. It’s easier to see progress when each step follows the other. Software development can take a long time before you see progress because of the parallel process of building parts.

4. Software has the concept of Minimal Viable Product. You start with a minimal version to get user feedback. Using the feedback, you adjust the goals and move forward towards the final product. Sometimes this approach feels like you build things the wrong way and have to start over again. Construction can’t afford to build a small house first to see if the windows are the ones the client wants. Construction relies on blueprints, 3D models, and other tools to simulate before start building. In software development, it’s easier to start building an MVP and gain user feedback – even if that means to start over again.

5. In construction, when the job is done, the contractor ships off to the next project. When the product is released in software development, this is often just the first step in a long cycle of continuous product development and support. The investment doesn’t stop after the release.

Custom Software Development, an Ongoing Process

So the traditional analogy to construct a building isn’t appropriate if you want to develop custom software today. The most important difference between building a bridge and creating software is that physical construction is a capital project, whereas building custom software is more of an ongoing operational project. Modern, lean software development uses the development capacity (also known as velocity), and frequent releases and the feedback, to iteratively build future proof and high-quality software than it would be otherwise.

If you understand the difference between building software as a capital project like a structure, versus building software as a function of velocity and frequent release, then the next question is, what are the processes one can use to do regular effective releases?

That’s a question we like to discuss with you before starting your next project with us.