Why building software takes time
Tags: softwareengineering, thoughts
Published: 2022-05-20 19:04:01

---
title: Why building software takes time
published: true
date: 2022-05-20 16:07:35 UTC
tags: Softwareengineering,Thoughts
canonical_url: https://www.rockandnull.com/why-building-software-takes-time/
---

 ![Why building software takes time](https://images.unsplash.com/uploads/14123892966835548e7bd/14369636?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDI3fHxjb25zdHJ1Y3Rpb258ZW58MHx8fHwxNjUzMDYyNzYw&ixlib=rb-1.2.1&q=80&w=2000)

It's difficult to explain to non-software engineers why software takes so much time to build. It's even more difficult to explain this to people who have **some** software experience but have never worked professionally or it's been too long since they wrote software.

The **first issue** is that software is like an iceberg. What you see it's just the top of it. The majority of the work is underwater, and it's invisible.

![Why building software takes time](https://www.rockandnull.com/content/images/2022/05/image.png)
_From iStock_

This is what troubles most people who have no experience developing software. They can't grasp how difficult could be to add a couple of buttons on the screen and then execute what seems like a pretty simple functionality. Of course, anyone who created software could explain that creating user interfaces, backend services, database models, or any other necessary component, and connecting all those components takes more. But excluding the UI, the rest of the components are hidden from the non-eng user so when they learn about their existence they tend to underestimate the amount of work required.

The **second issue** , which affects mainly people who have never worked professionally or it's been too long since they wrote software, is why do we bother with software architecture, and spend time organizing/refactoring the code.

For a certain kind of people, any time not spent on feature developments, or at least visible changes, is wasted time. They might even claim that splitting the code into different files, directories, or even modules, just makes the code more difficult to parse.

Most software engineers reply to this argument with mostly ethical arguments, such as "software is my craft" and take architecture and design as moral subjects.

But this might not be the right approach. You see the most important reason to care about software architecture and spend time on it, is that it's profitable.

![Why building software takes time](https://www.rockandnull.com/content/images/2022/05/image-5.png)
_Having food architecture is slower at the beginning, but faster over the long run (excellent watch). From Martin Fowler's Design Stamina Hypothesis._

It might take a bit more time, in the beginning, to set up the "right" architecture (for some definition of "right" - the best choices with the available initial data), but this will pay off relatively early when adding more features during the lifetime of the software. On the other hand, spend no time on organizing your piece of software, and you might get a head start, but adding features will become a pain relatively quickly until it just becomes impossible (at which point re-write would be the only option - which of course will be costlier).  

Hopefully, this small "rant" resonates with you and might be useful as a short explanation when someone asks why it takes so much time.

Happy coding!