Image by Pete Linforth from Pixabay

A long time ago, I had a discussion with a software architect working for a consumer electronics company. We talked about development efficiency and he explained to me the economics of high-volume manufacturing. When you manufacture a million televisions and you can squeeze one euro out of the bill-of-materials cost, you’ve made the company a million.

This concept has of course spread far and wide in the industry and virtually any company has cost-down initiatives where, also after the initial release of the product, redesign efforts take place to squeeze the bill-of-materials cost. …


Photo by Alex Wong on Unsplash

In the software community, there’s a general belief that software ages, just like humans — David Parnas is famous for this quote (among many other things). Our findings don’t confirm this. We’ve studied architecture technical debt as well as other types of technical debt for a decade and we’ve generated all kinds of results. One of our most surprising findings, resulting from a survey with hundreds of respondents, was that there seems to be no correlation between system age and technical debt.

Our hypothesis to explain this is that there always is technical debt but that the type of debt…


Photo by Nicolas Thomas on Unsplash

There are few topics in software development that can get people going as much as testing and quality assurance. The notion of shipping low-quality code to customers feels like a humiliation to most engineers. It causes a perception of abusing the customer for testing purposes, which doesn’t sit right and to many feels like a way to get disrupted really fast.

Although everyone agrees that software needs to be tested and be of sufficient quality before shipping to customers, the discussion is often concerned with how to achieve that desired state. …


Image by PIRO4D from Pixabay

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 once development is underway. So, the software architecture community, including me, developed all kinds of tools and techniques to structure and provide systematic means to take architecture design decisions, assess the architecture’s ability to meet the non-functional requirements, such as performance and maintainability, and ensure the alignment between requirements and the architecture.

Although these techniques…


Image by Steve Buissinne from Pixabay

Building software-intensive systems from scratch is far from trivial. One of the main reasons is that it’s hard to capture concisely and precisely what the system should look like in terms of functionality. Even if all stakeholders individually have a clear understanding of what they want, it doesn’t mean that the expectations are aligned. In many cases, there are conflicting needs and wishes that need to be managed.

Traditionally, this is addressed by embarking on a requirements elicitation process where the needs and wishes from all stakeholders are captured, conflicts are identified and resolved, resulting in a clear and crisp…


Photo by Fredy Jacob on Unsplash

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…


Photo by Alina Grubnyak on Unsplash

Traditional business ecosystems were quite static. Partners stayed partners, competitors stayed competitors and your customers were the same as who they were yesterday. In a digital world, however, business ecosystems are in continuous flux. Your supplier becomes your competitor. You become your customer’s competitor. You partner with companies that you never heard of a month ago.

There are at least three patterns causing business ecosystems to undergo continuous change. First, digitalization often changes the business model from transactional to continuous, eg subscription based. As a result, the company providing the product wants to own the customer relationship as it simplifies…


Image by Gerd Altmann from Pixabay

For the longest time in the history of humankind, we lived in a world defined by scarcity. Forests for hunting, land for agriculture, wood for construction and mining sites — all were scarce resources that many wanted to have, and consequently, we competed. Individuals competed against individuals. Tribes competed against tribes. Nation-states competed against other nation-states. The core mindset was that if one gets the resource, the other loses it.

Even when humans collaborated, the overall goal still was to outcompete other groups and within the groups, hierarchies developed with those higher up in the hierarchy looking to control those…


www.picserver.org

Little known fact: the original schools, started in the 19th century, had the goal of training obedient factory workers. The whole notion of sitting still at a desk, taking instructions and following orders was quite alien to many who had grown up on farms. For the factory owners to have access to workers, it was necessary to train people to take instructions from managers. In many ways, the school system of today follows that tradition and kids are taught to be quiet, disciplined and reactive.

In the digital age, obviously, waiting for someone to tell you what to do is…


Image by lifestylehack from Pixabay

The traditional way of organizing companies was in functional departments where people with the same skillset and education could focus on specific challenges, solve these and then hand over the result to the department that would integrate all the parts from all the functions into one working system. The perceived advantage was that each expert could just focus on his or her domain and not bother about anything else.

In practice, that model didn’t work very well and the inter-team coordination cost easily skyrocketed as each function made all kinds of assumptions about the other parts of the system that…

JanBosch

Academic, angel investor, board member and advisor working on the boundary of business and (software) technology

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store