I was thinking about why most companies treat the process of building software so much different to building real-world infrastructure.

In this post, I want to bring up the conversation that we have to treat building software more like building real-world infrastructure. And when I talked about this with others, we were more surprised than before! Why didn’t we, as software developers, treat our job that seriously?

1. Requirements

Let’s start with how we handle requirements in software development. And I know there are different kinds of companies working on a bigger scale of software development than others, but hear me out.

Software development

In my last ten years of software development, I’ve seen a variety of ways of collecting requirements. Most of them didn’t take it that seriously and were really agile minded. Well, agile, actually they didn’t really have an idea of what they were building.

They had issues with creating a plan, instead, they just started coding. There were no requirements, just an idea of what we needed to build. We had to figure it out along the way. Those projects, sooner or later, were left stranded because of a lack of clear vision.

Real-world infrastructure

When a building, bridge, shopping mall or any other infrastructure in the real world needs to be built, people first start discussing the requirements.

What end-user do they have in mind? What is the problem that needs to be solved? On which piece of land does it need to be placed? Why would people want to use it? And so on.

That are quite a few questions that need to be answered to make a good list of requirements. I guess my questions are just a small part of it.

But why do people that build real-world infrastructure take this so seriously?

Well, they don’t want to waste money. They don’t want accidents to happen. They want to create a success story for their end-users. And of course, they want to earn money.

Real-world vs. software development

Well, when I thought only about this, I had the feeling, why oh why do most of us, people who build software for a living, not serious about having proper thought-through requirements?

Don’t we care? Don’t we want to build a success story for our end users? Do we want to waste money? I don’t think so!

Neither will your boss think like this. But how should they know? Most likely, your boss isn’t a software developer, architect, or designer. And if your boss is that, would you listen to it?

Don’t get me wrong, I don’t want people to be angry or upset with me!

But I think that we, as software developers, have to take our requirements more seriously. We have to have more pride in our work. To advise those people, we have to come up with those requirements.

2. Flexibility

There are quite a few differences in terms of flexibility if you compare software development to building real-world infrastructure. But, let’s dive into it a bit, to see if it really differs that much, or do we software developers just push new things through?

Software development

For a couple of centuries, we have been transitioning from waterfall to agile.

With waterfall, all the processes are lined up and are following an order. Writing requirements, building the software, testing the software, and releasing it.

At first, this doesn’t sound too bad. But when somewhere in between there was an issue, everything was moved for months before people could test the software.

That didn’t work out so well, so a few smart people came up with the Agile Manifesto. A few guidelines that could be used to build a more flexible way of software development. Because, along the process of development, the requirements could change.

They could change because users gave feedback or people performed tests with the software.

Or maybe the company of the software didn’t know the real problem to solve for their users. So, the agile guidelines should make the development of an application a learning process where agility is key for a business to succeed.

But when a company transitioned from waterfall to agile, they thought they didn’t have to have requirements anymore, and that they could throw up any change when they wanted, without realizing the effect of it. That causing problems.

But how to work agile as a software company is more than enough to write a whole book about (or a series of posts).

When the company has worked on its requirements and has that worked out really well, the impact can be minimized. But most of the companies don’t spend their time working out their requirements.

So, the impact is, most of the time, bigger than estimated. But if a requirement is changing or we need to update a dependency, or we change from one framework to the other, everyone takes this very lightly.

A lot of people don’t realize the impact of those changes! Hopefully, you’re not one of them! If you are, please continue reading.

Real-world infrastructure

When there are changes during the building phase of real-world infrastructure, everyone knows that it could have massive consequences in terms of money or when the building will be done.

When a change has to happen, the whole process needs to be paused. It also depends on the impact of the change. But the effect could be quite big.

So, the whole building team, architects, and other people have to go back to the drawing board. A change in the requirements can have a massive impact! Everyone in the team will know that.

Because they are aware that every change is going to cost more time and money. And potentially be a risk for the success of the project.

Real-world vs. software development

If I compare both worlds with each other, I think we have to be more aware of the impact of changes. Changes of dependencies. Changes of an architectural change. Every change should be properly investigated before someone makes a decision.

When we are more conscientious about the impact it has for a business in terms of time and money, we wouldn’t think that lightly anymore about architectural changes.

So, let’s make each other aware of it. Take pride in your job!

And if you’re very aware of the impact that we could potentially cause, it’s your duty to advise the people who are making the decisions.

3. Maintenance

When we think about maintenance, we know both software development and real-world infrastructure can’t live without it. But there are quite a lot of differences between how companies handle maintenance on a piece of software vs. real-world infrastructure.

Software development

I’ve seen many companies that had no people in place to take care of the maintenance of their software. Even more, companies are surprised when you ask them to have people in place once the development phase is finished.

They really look like they see water burning!

Well, maybe not all companies think that lightly about software maintenance. Thank God there are good companies that have people in place to update their software once it is released. Or people that are fixing bugs or even better, they improve the software.

But in smaller companies, it’s not very common to have people do that.

Most managers in those companies think about this like: “Well, the development team should make the software future proof or should not introduce any bugs.”

Well, hopefully we all know by now that people are not perfect, so software is never done.

Real-world infrastructure

In terms of maintenance for infrastructures like roads, bridges, houses, or other buildings it’s very common to have people for that maintenance.

Your house probably needs some maintenance every now and then like painting walls, fixing the roof, fixing leakage, etc. Or you hire a company that does this for you.

But everyone knows real-world infrastructure needs maintenance, otherwise, it goes bad.

Every now and then, our roads need a new layer of concrete. Our wood needs new paint or needs to be fixed because of its environment.

Software development vs. real-world infrastructure

The mind-blowing thing about maintenance is that a lot of companies don’t even consider this part. They just blame it on the developers, that they have to have bug-free software or that they have to build it for the coming ten years.

But let’s be honest, we don’t say these things to people that are building our houses, roads, bridges, and other real-world infrastructure. So why do we expect our software to be maintenance-free?

Servers get security patches and frameworks get bug fixes. We all want the software that we work with every day to be better and safer in the future, right?

I hope your company does a great job with this! If so, high five, my friend!

But let’s help other people, software developers, and companies be more aware of this part of software development.

Conclusion

Thanks for reading everything here!

I hope that my story has woken some people up, and that we as software developers are more aware of the fact.

Software development doesn’t differ that much from building real-world infrastructure. So let’s treat our software development a bit more seriously and be more conscious about the impact we have on it.

We can make or break a company with our seriousness or lack of it. Let’s be proud of our job and be more serious about it!

If you agree or disagree with me, please let me know in the comments. I’m looking forwards to having a good conversation about making our job better!

Do you want to learn to create content for developers and programmers like me? Signup for my FREE email course!

Read More From Me

2 Ways to Resolve Duplication in JavaScript Arrays and Objects
_Do you know how to deal with duplication?_medium.com

Make Your JavaScript Objects More Predictable by Creating Maps
_No more undefined properties_medium.com

How To Earn Money As Programmer During The Coronavirus
_3 Ways Programmers Can Get Paid Without The Need Of A Job_medium.com

What Is The Scope In JavaScript
_Explanation about the behavior of Var, Const, Let, Functions, Objects, and Classes in the Global Scope._itnext.io