Kosli devops change management Jan Bosch 10 outdated beliefs about software

10 outdated beliefs about software

Jan Bosch
Jan Bosch
Published June 29, 2021 in features

The world of software remains a fascinating place and I keep being amazed at how rapidly it continues to evolve and transform. We certainly have come a long from the early 1980s when I was a teenager programming BASIC on my ZX81. Especially for those of us who have been in the field for decades, it’s critical to continuously reinvent ourselves and our beliefs about the domain to make sure we don’t get stuck in the old ways.

Unfortunately, I still run into a lot of very experienced people who in some way “didn’t get the memo” and are operating on an outdated belief system about software. This isn’t just the case for practitioners but also for customers, managers and senior leaders. To address this, I assembled 10 beliefs about software that I run into regularly and that in my experience are outdated and no longer true for most contexts.

1. Clear, precise requirements are instrumental for success

No individual or group can build a system without an understanding of what it should look like. Traditionally, we used requirements, defined at the start of the project, to describe the desired outcome and assumed that if we’d build the system according to the requirements, we were fine. However, requirements change all the time, capture less than 10 percent of what was really intended, easily slide into specifying solutions, are often used as an excuse and easily move us away from the outcomes we’re really looking to accomplish. In many domains, it’s better to accept that the full scope of the system will only become clear during the project, things change constantly and there are better ways than upfront defined requirements to manage the system’s functionality growth.

2. A carefully designed architecture is critical

In the early 2000s, I was one of those people preaching the importance of careful design and analysis of a system’s architecture before starting development. The belief was that especially non-functional requirements, such as performance and robustness, are hard to ‘bolt on’ to the system after development has started. Today, it’s clear that the architecture of a system evolves continuously in response to new requirements, evolving technologies, changing user behavior, and so on. And it’s entirely feasible to change the non-functional characteristics of existing systems by evolving their architecture.

3. Slow, manual testing is superior to automated testing

One of the most persistent outdated beliefs I run into is that manual testing at the end of a waterfall-style project is superior to continuous, automated testing in terms of accomplishing quality outcomes. The more safety-critical and complex the system at hand, the more this belief tends to be prevalent. Although our research shows that automated regression testing benefits from being complemented with exploratory testing by humans, it’s obvious that testing a system extensively and frequently through automated means has to be superior to less frequent and less elaborate testing.

4. Technical debt means you did a poor job designing your architecture

Especially customers of complex software systems and more senior managers tend to believe that if you need to address technical debt, it’s because you or someone else did a poor job at some point in the past. Our research shows that all systems, independent of age, contain technical debt and the only way to handle it properly is to continuously invest a certain percentage of the R&D resources into managing it. As expectations are constantly shifting, the architecture and design of the system are never optimal for what we want from the system right now.

5. Bill of materials trumps everything

In the embedded-systems domain, one of the broadly held beliefs is that reducing the bill-of-materials (BOM) cost for a product justifies any R&D expense as, especially for high-volume products, this one-time expense is outweighed by the savings generated for each manufactured product. In most contexts, this is no longer the case. Typically, the savings from squeezing electronics are minimal, but the more important reason is that most systems are now expected to evolve during their lifetime. If you have no headroom in the product, it’s impossible to deploy improved software to it and you’ve painted yourself into a corner.

6. The data is owned by the customer and we can’t monetize it

Especially in companies that started their life in mechanical engineering, there’s a broadly held belief that the data generated by the product sold to a customer is owned by the customer and we can’t use or monetize it. Data is an asset, just like software, patents and designs, and who owns the asset is a matter of contracts. If your agreement with the customers states that you own the data generated by the product, even though the customer is the legal product owner, then you own the asset and can monetize it.

7. Post-deployment is relevant only for (serious) quality issues

For those of us who grew up in the age of expensive product recalls due to the first software issues, patching software in products deployed at customers is something only considered as the last resort. Times have changed, however, and virtually all products are connected and deploying new software is virtually free. In addition, customers are increasingly expecting a product that continuously gets better. Consequently, continuous deployment of new software to products out in the field is increasingly becoming the norm.

8. A/B testing is only for online systems

Especially in the embedded-systems domain, where I spend a lot of my time, many still believe that A/B testing is only relevant for the large SaaS providers. In the age of connected systems and DevOps, it’s of course entirely feasible to run A/B tests in embedded systems as well. And it often is superior to some engineer guessing what the best way to realize some functionality is. As the saying goes: if you don’t know, experiment.

9. We can’t do DevOps because we need safety certification

Change is difficult and painful and many tend to look for excuses why they’re special and can stay with their current ways of doing things. Especially in cases where safety certification or other forms of regulatory approval are required, many hide behind that to avoid having to adopt more modern engineering practices. There are several examples out there of companies that push software frequently even to systems that have high-reliability requirements and even regulators are starting to push for fast updates in response to, for instance, security risks.

10. It’s only about the customer and us

There still is a widely held belief that if we focus all our energy on the customer and build what the customer tells us to build, we’re going to continue to be successful. In a digital world where change is faster than ever, this view is no longer sufficient. We need to take a more holistic perspective, understand we operate in an ecosystem, that disruption comes out of left field and that the solutions you provide your customers with don’t operate in a vacuum but in an often surprisingly complex context.

The software industry is fascinating because it evolves so quickly. As professionals, this requires us to reinvent ourselves continuously, question our beliefs and accept that what was true at some point in the past perhaps is no longer true or no longer the optimal way. Letting go of old beliefs that we’ve held onto for a long time is hard, but belief systems are like houses you live in for a while: you need to move on to grow and develop. The only ones that don’t grow and develop are the dead ones. And who wants that?

From more insights from Jan you can sign up for his newsletter and follow him on LinkedIn and Twitter at the links below.

jan@janbosch.com

janbosch.com/blog

linkedin.com/in/janbosch

@JanBosch


About this article

Published June 29, 2021 in features

About the author

Jan Bosch

Jan Bosch


ABOUT THIS ARTICLE

Published June 29, 2021, in features

AUTHOR
Jan Bosch
Jan Bosch
Live in Git Blame? Don’t spend hours searching for the change that broke your application! Query, search and discover all the changes in one place

Latest articles

Kosli announces Innovation Partnership with DNB and Firi

We are pleased to announce that Innovasjon Norge has awarded Kosli an innovation grant of 3.4 million NOK to pursue a R&D project with DNB and Firi. In this blog we’ll give you an overview of the …

The Ultimate Guide to git blame: A How To with Examples

Source control tools give users many powers and one of the big ones is traceability. With traceability tools you can know exactly who made each change and when they made it. In Git, you use the git …

Git Blame in VS Code: The 4 Best Options

Most production projects have a team collaborating on them, so even in a single file there can be multiple contributors. When things go wrong, it’s useful to understand how and why certain changes …

Sign up to our newsletter

We'll let you know about the Kosli launch, product news, features and updates
Kosli is committed to protecting and respecting your privacy. By submitting this newsletter request, I consent to Kosli sending me marketing communications via email. I may opt out at any time. For information about our privacy practices, please visit Kosli's privacy policy.
Kosli team reading the newsletter

Let’s chat!

Got a question about Kosli? An idea for a new feature? Join Kosli Slack and talk to us.

Join
Developers using Kosli