Why software engineering should be rocket science

I am not a software architect. I haven't studied computer science. I understand algorithms, did some coding in extremely marginal languages decades ago, but mostly I understand what computers can do and what they cannot do. And I've learned a lot on the job of being a de facto product manager with some CTO tasks. I'd like to share some experiences on making architectural choices with you, while taking some wisdom from other disciplines - and from a person who showed it's not always a good idea to use the latest and greatest.

Ask yourself: if you were an architect, would you want to work with proven technology from decades ago, or would you rather use recent technologies that take the possibilities to the maximum? Good chance you'd prefer the latter. What's more: if you're a good, well informed architect, you'd be prone to be completely up to date with respect to available technologies and probably biased towards using those. Because they stretch your possibilities. But is using the latest technology always a good idea?

Help from space

There is not a clear answer to that question. But let me start with an example from space. What kind of CPUs do you think are being used in modern spacecraft? The latest, fastest and neatest? Wrong. Generally, a CPU on board of a flight computer on a spacecraft will be at least a decade old. Why? Because it has been thoroughly tested, bugs are known, and the lesser miniaturisation will make it more reliable when encountering cosmic radiation.

Whereas your mobile phone will probably have (much) more computing power than an average CPU on a spacecraft, and you think you need that speed (and if you're a gaming enthusiast you actually might) - engineers working on a spacecraft will use what's robust, proven and sufficient to what is needed. No fancy user interfaces, but fully redundant flight computers well able to do the necessary calculations for navigation, but no more than that.

Delivering pizzas

A good software architecture should be proportional to what you're aiming for with the software. In terms of transport: if you deliver pizzas in a medieval city, you can be sure that the pizzas will fit in a truck, but you cannot be sure that the truck will fit into the cobble-stoned narrow streets and alleys of that city. Your better bet is a bicycle, a scooter or a small van. What's more, if you're planning to grow your business, your better bet is a bunch of scooters rather than a even bigger truck.

This simple fact seems to be overseen many times when building software. Designing a new software architecture might induce scope creep: 'What if we would be able to handle millions of users and their data?' is a silly question when you only have dozens of customers. There's quite a lot of questions to be asked when making architectural choices. First, there are a the following questions with respect to the fit between the architecture and the envisaged software product:

• Is the software product experimental, like in the early stage of a start-up? Can you (or rather your customers) cope with downtime?
• What is the risk you're willing to take with respect to outages taking place? The answer will be related to your business model and service level agreements.
• What are the chances that you will be scaling up to large numbers of customers (putting stress on search engines, databases, web services etc.) in the foreseeable future, where a simpler architecture would no longer suffice?
• Do you have many corporate customers? Take into account that most state of the art front end frameworks might give problems when using old web browsers. Corporates love using old browsers.
• How will customers respond to any possible data loss or delays in updating data points to their latest 'state'?

Second, there are the following questions with respect to the envisaged architecture and its components themselves:

• What is the track record for any new components you might want to employ? Are they 'established technology'?
• Are there experiences with the specific combination of components in the architecture? Are there any unenvisaged interactions or dependencies?
• Apart from commercial licenses, do you need support licenses for open source products?
• Which components would be bottlenecks when scaling up, and how hard would it be to replace each of those individual components?

Of course, most relevant questions will depend on the specific nature of the envisaged software product, and it's impossible to list such here. However, scaling down the complexity of your envisaged software architecture might be a good idea to reduce initial investments. Of course there is also a flipside to that coin, in terms of the lifecycle of components you use, and critical outages or impossibilities when scaling up in terms of number of customers or functionalities.

You should keep in mind that, while proven technology should be fine, if a component is near the end of its lifecycle, it's not a good idea to use it because you may run out of support. Moreover, using older technology may be a rational choice from a cost/maintenance point of view - but you should consider that the brightest minds will generally prefer new technology and might skip your job offer for a more technology-savvy employer.

Final words

While I'm not such an enthusiastic supporter of agile methodologies, because they have a tendency to encourage sloppy product development, I can see the benefits of trying to make your effort proportional to the goal you're trying to reach. If it doesn't work, try something else. It is important to guard proportionality in making architectural choices. Being too ambitious with requirements regarding an architecture might cause higher-than-necessary costs at the least, and possibly unforeseen consequences of complexity.

How are you rationalising your architectural choices? Please share your thoughts in the comments.

Laurens Mommers

Interested in more posts on software product management?

How to improve software products by making them simpler - why less is still more

Why you need a healthy dose of marketing in product management

Why software engineering should be rocket science

How to handle cognitive biases in product management

Bob Ross was the real father of the agile movement - and why that is bad news

What software product managers can learn from the current 737-MAX crisis

Seven golden rules to avoid software becoming a Christmas tree

Seven secrets of building beautiful software

Building compliance software: five major pitfalls and how to deal with them