Why Building a Software is Different than Building a House
Maybe you're not much experienced in software development and working on or thinking about your own digital product. On the other hand you consider yourself as a one with a strong background in building houses — or some other activity from the physical world. Here's why you should avoid the temptation to apply the same logic you know from building houses to build a software.
A common issue for people coming from non-software domains is that they're trying to apply the logic working in the physical world on the digital one.
Difference n. 1: When you build a house, you usually know how many people will live there.
You are probably a couple planning to have 1–3 children. Then you plan a house, its disposition, for 2–5 people.
On the other hand when you plan a software product, you wish that 1,000 people use it, you know that 1,000,000 actually can use it in some moment in the future and 0 (zero) actually uses it.
Difference n.2: When you build a house, you usually know how you will use it.
You know that you need some space to sleep and that you sleep once a day on average. You need a kitchen to be able to prepare a meal. You need a toilette and you know, that you'll have to visit it 3 times a day on average. Hence the basic architecture is somehow given with low probability of failure.
When you build a software, you do not know which features will be adopted by your users. The only thing you can do is to try, measure and then decide.
Difference n.3: Rebuilding the basics of a software is quite easy comparing to rebuilding the basics of a house.
As far as I know, you can't just change the basics of the house without destroying it and building a new one. But the software is different.
It's mainly because of differences mentioned above and the high risk while building a digital product. That software has to be easily maintained even in its core. You don't need to destroy the whole application and build a new one. You can simply modify it.
There are tools, methods and processes like microservices architecture, continuous integration and dozens of others to achieve this. Unlike basics of house, basics of software can be and should be continuously revised and rewritten — software teams call this activity a refactoring.
The initial thought is, do not waste time and budget on something you don't feel absolutely necessary now. You can do it anytime in the future. Do you think Facebook was initially build for billions of users monthly?
What you can get from it
Building a software is different than building a house. The main reason is that when building a house, you can use a priori assumptions that can't be far from reality, e.g. number of occupants. If you build a software, you should avoid it because your a priori assumptions can — and usually are — far from reality.
The good thing is that you don't have to. Good software team will guide you through this process and will — in each stage of development — apply the solution that best fit the actual problem. I'll conclude with a short recommendation.
When building a software, deal with the problems you actually do have. Do not try to solve the problems that may occur in the future.
What if you do not
If you can't avoid applying the logic from the physical world to software development, be ready to pay costly infrastructure. Because in a year or two you think you'll need it. You'll invest in performance testing, checking whether your software can serve thousands of users, while you have none. And 1,000 users is nothing than a dream.
Feel free to share your opinion and experience in the comments below. Looking forward to it.
If you're looking for a software development partner, invest in a short talk with us — guys at NETVOR.