House Building as a Metaphor for Software Development

When explaining our software development process to clients, the Lab3 team often finds itself comparing developing software to the building of a house. On the face of it, there are a lot of similarities between the two. Making last minute ‘minor’ changes to functionality is a lot harder than if it was planned, for example (like changing a room to be a bathroom will involve much more expensive plumbing than if it was always the plan). Does the model always apply, though? I analysed our recent projects to find out.

The Metaphor in Practice

Most people understand that changing things that have already been made is difficult. It’s easy for most people to understand the physical world; when your builder tells you that it’s not going to to be easy to put a different shaped window in the hole he’s already cut, it’s not hard to see why. Software is, however, far more intangible. Swapping a piece of functionality for something similar can be as complicated as switching window sizes. On the other hand, in some cases it can be super easy – and this is the problem. To everybody who doesn’t understand how a particular program was implemented, the rules for when something will be expensive and when something will be cheap are very unclear – even to other developers.

The cost benefits of planning ahead are also similar. Adding a new room to your build at a late stage might bring a whole range of problems. Your foundations might not support it, and the hours spent on the section of wall you’re removing will go to waste. In the same way, software projects are designed – ‘architected’ – with a final product in mind. The technologies chosen and the structure used all might make sense for a given solution, but could be inefficient and wasteful as the project changes.

Maintenance is another area where house and software are similar. We all want things to be ‘solid as houses’, but if you think about it – houses do take a lot of maintenance. Just like wear and tear causes houses to be bit-by-bit replaced over time, software will never keep working as it may once have. Everything moves on without it – underlying platforms change or security vulnerabilities are found in other software you depend on.

Why It Doesn’t Always Apply

Our ‘house building‘ metaphor isn’t perfect though; in some ways, software is very different. For one thing – it’s not constrained by the same physical laws. Building a four bedroom house on the footprint of a motorhome is physically impossible. We can still make the software equivalent, it just probably isn’t a very good idea.

Another thing that adds to the flexibility of software development is in the way ‘construction’ takes place. Our team, as is quite common in the industry, uses ‘Agile’ development methods. This means that we build things room by room, and that at every stage there is a usable ‘house’ – even if it’s just a standalone kitchen. Compare this to your average house build; the frame goes up first, followed by roof, cladding, and windows – the house is built as one item. When building a house, changing anything means working within the confines of what you have already established, and you only get the value at the very end.

The needs of the client are very different, too. During the course of a building project, it’s unlikely the needs of the client will change. If they do, it’ll be minor – maybe they need four bedrooms now, not three. Software projects are often so exploratory, that the original requirements might be completely useless within the first few weeks of development. We try our best to fix these requirements in place before a project starts, but sometimes we do need to make changes to align with the business case.

It’s clear that while it is a useful model for explaining how some parts of software development work, the ‘house building’ analogy is far from perfect. When it comes down to it, though, you can improve a software build with good planning and management in all the same ways that you can improve the process of building a house.

So you want an app, but do you really need one?

Wait, what do you mean by ‘app’?

Most people associate ‘apps’ with the ones found on mobile phones. The pieces of software we use every day; designed to connect people, read the news and take selfies. You’d be wrong however to think that apps start and end there. Mobile apps aren’t the only kind of apps there are.

‘App’ actually has a wider meaning in the tech space. For example, a website can be an app, a ‘web app’ – they do more than just deliver information, they offer interaction; ‘web apps’ with integrated app-like features are called ‘progressive web apps’; and good old-fashioned ‘programs’ or ‘applications’ for your desktop have been rebranded as ‘desktop apps’.

For a lot of companies, the same product can cover all of these categories. Take Facebook for example. Facebook is a web app, the mobile site is a Progressive Web App, and it has mobile apps too.

Here, we’re mostly addressing mobile, app-store-based apps.

Have you considered that you might not need an app?

The natural tendency these days when faced with a problem is to solve it with an app. Modern culture revolves around apps. In fact, according to the Flurry State of Mobile 2017, 92% of your daily phone use is spent in an app. The only problem – roughly 90% of the time you spend on your phone is on the same 5 apps. People don’t use Facebook, Instagram and Twitter because they’re apps, they use the apps because they are Facebook, Instagram and Twitter.

The concept of ‘App Fatigue’ is something that’s emerged with the abundance of mobile apps. It’s become harder to differentiate your product or demonstrate a unique characteristic. In fact, most people don’t install any apps in a given month. That’s not to say that producing an app is a terrible idea, far from it. For the services we use daily, having apps available on our phones is an invaluable convenience. Product developers just need to consider the value that having an app will bring to their users. At the very least – consider whether releasing your product first as a Web App, or Progressive Web App might allow you to test your market, without significant extra investment.

Okay, so you want a mobile app – what are the options?

You’ve weighed it up, considered your user’s needs, and you want that app. Now what happens? Well, unfortunately, mobile apps are just as confusing, and have just as many options as the term ‘app’ itself.

Broadly speaking, apps are either ‘native’ or ‘cross-platform’. A native app is written specifically for a particular platform. That means a native app made for iPhones, can only run on an iPhone. Native apps typically deliver the best experience to the user. When done well, they’re fast, elegant, and generally just feel good. But, they come with the downside of often being slower and more costly to develop, and you still end up with an app that doesn’t reach 100% of the mobile market share.

An alternative to native apps are cross-platform apps, which aren’t written for any particular platform. Cross-platform apps that are written once can run on multiple platforms – iOS, Android and more. The huge benefit here is that developers only need to worry about developing the one product.

So then what are the downsides of cross-platform? It used to be that native apps were always viewed as ‘better’ – they were faster, and felt more natural for the user. Cross-platform apps were not quite as good as native apps, but they were a lot cheaper – allowing developers to reach multiple platforms with only one app. Despite this, cross-platform apps have come a long way, and in recent years the performance advantage of native has narrowed significantly. It’s still probably fair to say that all else being equal, a natively developed app will never be worse than its cross platform equivalent – the best cross platform apps can hope to be is as good as native.

How much will it set me back?

Apps of course come in many different shapes and sizes, and it’s very hard to give a one-size-fits-all price indication. The price of an app depends not only on what features you want, but who is developing it, and what technologies are used.

Our recommendation is to find a suitable developer and discuss your product with them. The worst that’ll happen is that you’ll learn more about the problem you’re trying to solve. Hear from several developers before committing to one and ensure that their outcomes match your expectations. For us, this means understanding the problem you’re trying to solve and making sure that the proposed solution meets that in the best way possible. If not, then there’s no shortage of options to choose from!

Get in touch to talk to us about your app.


Cross-Platform Development

Lab3 is a cross-platform development company, but what does that mean? In a nutshell, cross-platform development is using one codebase to maintain apps on many platforms.

In practice, there are two ways to do this. The first option is to compile the code into the native language used on different platforms. The second is to develop using a framework that is runnable on different platforms. These different approaches offer different benefits. At Lab3 we tend to use the second method – using a cross-platform framework called Ionic. Ionic apps are web technology based. This means we write the apps in HTML5, CSS3 and JavaScript or TypeScript. This makes UI design very flexible compared to native app development. All the native functionality of different devices are still available, via plugins. This includes cameras, GPS, and all the other functionality of a modern mobile device. 

We’ve found that by using Cross-Platform development, we can provide phenomenal value to our clients. For a development cost not much higher than a single platform when developing natively, we can reach Web, Desktop, iPhone, Android and Windows Phone. Not every app can work well in a cross-platform format, but in our experience, a lot can!