{"id":1264,"date":"2021-06-09T11:40:08","date_gmt":"2021-06-09T11:40:08","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1264"},"modified":"2021-06-09T11:40:09","modified_gmt":"2021-06-09T11:40:09","slug":"10-outdated-beliefs-about-software","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/06\/09\/10-outdated-beliefs-about-software\/","title":{"rendered":"10 outdated beliefs about software"},"content":{"rendered":"\n
\"\"
Photo by Fredy Jacob on Unsplash<\/figcaption><\/figure>\n\n\n\n

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\u2019s critical to continuously reinvent ourselves and our beliefs about the domain to make sure we don\u2019t get stuck in the old ways.<\/p>\n\n\n\n

Unfortunately, I still run into a lot of very experienced people who \nin some way \u201cdidn\u2019t get the memo\u201d and are operating on an outdated \nbelief system about software. This isn\u2019t just the case for practitioners\n but also for customers, managers and senior leaders. To address this, I\n assembled 10 beliefs about software that I run into regularly and that \nin my experience are outdated and no longer true for most contexts.<\/p>\n\n\n\n

1. Clear, precise requirements are instrumental for success<\/h3>\n\n\n\n

No individual or group can build a system without an understanding of\n what it should look like. Traditionally, we used requirements, defined \nat the start of the project, to describe the desired outcome and assumed\n that if we\u2019d build the system according to the requirements, we were \nfine. However, requirements change all the time, capture less than 10 \npercent of what was really intended, easily slide into specifying \nsolutions, are often used as an excuse and easily move us away from the \noutcomes we\u2019re really looking to accomplish. In many domains, it\u2019s \nbetter to accept that the full scope of the system will only become \nclear during the project, things change constantly and there are better \nways than upfront defined requirements to manage the system\u2019s \nfunctionality growth.<\/p>\n\n\n\n

2. A carefully designed architecture is critical<\/h3>\n\n\n\n

In the early 2000s, I was one of those people preaching the \nimportance of careful design and analysis of a system\u2019s architecture \nbefore starting development. The belief was that especially \nnon-functional requirements, such as performance and robustness, are \nhard to \u2018bolt on\u2019 to the system after development has started. Today, \nit\u2019s clear that the architecture of a system evolves continuously in \nresponse to new requirements, evolving technologies, changing user \nbehavior, and so on. And it\u2019s entirely feasible to change the \nnon-functional characteristics of existing systems by evolving their \narchitecture.<\/p>\n\n\n\n

3. Slow, manual testing is superior to automated testing<\/h3>\n\n\n\n

One of the most persistent outdated beliefs I run into is that manual\n testing at the end of a waterfall-style project is superior to \ncontinuous, automated testing in terms of accomplishing quality \noutcomes. The more safety-critical and complex the system at hand, the \nmore this belief tends to be prevalent. Although our research shows that\n automated regression testing benefits from being complemented with \nexploratory testing by humans, it\u2019s obvious that testing a system \nextensively and frequently through automated means has to be superior to\n less frequent and less elaborate testing.<\/p>\n\n\n\n

4. Technical debt means you did a poor job designing your architecture<\/h3>\n\n\n\n

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

5. Bill of materials trumps everything<\/h3>\n\n\n\n

In the embedded-systems domain, one of the broadly held beliefs is \nthat reducing the bill-of-materials (BOM) cost for a product justifies \nany R&D expense as, especially for high-volume products, this \none-time expense is outweighed by the savings generated for each \nmanufactured product. In most contexts, this is no longer the case. \nTypically, the savings from squeezing electronics are minimal, but the \nmore important reason is that most systems are now expected to evolve \nduring their lifetime. If you have no headroom in the product, it\u2019s \nimpossible to deploy improved software to it and you\u2019ve painted yourself\n into a corner.<\/p>\n\n\n\n

6. The data is owned by the customer and we can\u2019t monetize it<\/h3>\n\n\n\n

Especially in companies that started their life in mechanical \nengineering, there\u2019s a broadly held belief that the data generated by \nthe product sold to a customer is owned by the customer and we can\u2019t use\n or monetize it. Data is an asset, just like software, patents and \ndesigns, and who owns the asset is a matter of contracts. If your \nagreement with the customers states that you own the data generated by \nthe product, even though the customer is the legal product owner, then \nyou own the asset and can monetize it.<\/p>\n\n\n\n

7. Post-deployment is relevant only for (serious) quality issues<\/h3>\n\n\n\n

For those of us who grew up in the age of expensive product recalls \ndue to the first software issues, patching software in products deployed\n at customers is something only considered as the last resort. Times \nhave changed, however, and virtually all products are connected and \ndeploying new software is virtually free. In addition, customers are \nincreasingly expecting a product that continuously gets better. \nConsequently, continuous deployment of new software to products out in \nthe field is increasingly becoming the norm.<\/p>\n\n\n\n

8. A\/B testing is only for online systems<\/h3>\n\n\n\n

Especially in the embedded-systems domain, where I spend a lot of my \ntime, many still believe that A\/B testing is only relevant for the large\n SaaS providers. In the age of connected systems and DevOps, it\u2019s of \ncourse entirely feasible to run A\/B tests in embedded systems as well. \nAnd it often is superior to some engineer guessing what the best way to \nrealize some functionality is. As the saying goes: if you don\u2019t know, \nexperiment.<\/p>\n\n\n\n

9. We can\u2019t do DevOps because we need safety certification<\/h3>\n\n\n\n

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

10. It\u2019s only about the customer and us<\/h3>\n\n\n\n

There still is a widely held belief that if we focus all our energy \non the customer and build what the customer tells us to build, we\u2019re \ngoing to continue to be successful. In a digital world where change is \nfaster than ever, this view is no longer sufficient. We need to take a \nmore holistic perspective, understand we operate in an ecosystem, that \ndisruption comes out of left field and that the solutions you provide \nyour customers with don\u2019t operate in a vacuum but in an often \nsurprisingly complex context.<\/p>\n\n\n\n

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\u2019ve 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\u2019t grow and develop are the dead ones. And who wants that?<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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, … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[12,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1264"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1264"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1264\/revisions"}],"predecessor-version":[{"id":1266,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1264\/revisions\/1266"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}