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.
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.
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!
Top comments (0)