Software engineering across domains

This week’s paper discusses how software engineering practices differ across domains. It is from 2019, the same year OpenAI proclaimed that GPT-2 was too dangerous to release and then released it anyway a few months later. Nevertheless, I think it still offers a revealing glimpse of different software engineering cultures and how these came to be, because cultural changes tend to lag behind technical changes.

The paper’s findings are based on interviews with 19 software professionals with experience in multiple domains, the idea being that this allows them to clearly state which practices differ or are similar across domains.

Interviewees who work or have worked in the banking domain often mention that while they usually practice continuous integration, they tend to be more careful with software releases in periods when financial transactions increase, mainly at the end of the year (due to holidays) and the beginning of each month (due to salary payments). During critical periods, developers mainly focus on fixing bugs.

As banking systems are highly regulated, code is often changed not only to add new features but also to comply with new regulatory demands.

Another characteristic of the banking domain is that it is very abstract and complex. This makes it hard to understand what stakeholders really want and requirements engineering highly challenging.

Developers in the e-commerce domain also occasionally put continuous integration on halt. In this case, it’s during periods when the amount of sales increases. During such periods, the priority is to fix bugs and give customers the best possible experience to entice them to fork over their money.

User-centred non-functional requirements such as performance, usability, and security play a larger role than in other domains. In some companies, this also affects how teams approach continuous delivery, which is done less frequently to allow for more time to extensively test code changes before they are put into production.

The healthcare domain is also well-known for being highly regulated, meaning that changes to software to meet new legal demands are prioritised over new features.

Many interviewees claim that requirements elicitation is easier in healthcare than in other domains due to higher qualifications of medical professionals, making communication easier. However, not everyone seems to agree, so it may depend on the involved individuals or companies.

A major challenge in the healthcare domain is interoperability between systems made by different companies. Despite the existence of standards, different hospitals may store and format information differently, making it hard to exchange information.

Finally, reliability, privacy and security of patient data play an important role in the development process, as any mistakes here can have very serious consequences for patients.

There were also some findings from other domains for which there were only a few interviewees. The authors seemingly weren’t able to confirm these, but they are mentioned nonetheless as they are still quite interesting.

The social network and search engine domains, for example, are characterised by a high degree of flexibility when it comes to releases and the work that developers want to take on. Developers are also more likely to test their own changes, whereas many other domains use dedicated testers.

Finally, software in the oil and gas domain must be extremely robust and be able to automatically recover from faults, as the systems running the software are often physically inaccessible for extended periods of time and thus cannot be serviced.