Blog on Uwe Friedrichsen

We are our own worst enemies

Fri, 24 Apr 2026 00:00:00 +0000

We are our own worst enemies

This post is about two observations I repeatedly make when looking around in our community. They are loosely connected by the topic of AI, which makes both observations more visible. The observations are about how we make our lives – IMO unnecessarily – harder.

Let us start with the first observation.

The perceived feeling of acceleration

My first observation in a nutshell:

The world does not accelerate that fast. We decided to accelerate.

It has never been about code

Fri, 03 Apr 2026 00:00:00 +0000

It has never been about code

The dream

It started many years ago with a dream – a dream about a universal automaton. Many people were involved in its invention: Ada Lovelace, Charles Babbage, Alan Turing, Conrad Zuse, and many more. John von Neumann came relatively late to the party, but he described a hardware design in 1945 that became famous as the “Von Neumann architecture”. Even if the technology evolved a lot and computers became much more powerful since 1945, more than 80 years later, the design of most modern computers is still a refined version of the original Von Neumann architecture.

In search of resilience

Fri, 13 Mar 2026 00:00:00 +0000

In search of resilience

AI is eating IT. At least this is how it looks at the moment. AI everywhere, in all stages of software development as well as part of the solutions, including SaaS and COTS. The promise and widespread AI application pattern:

Make developers hyper-productive using AI to fix existing issues in IT, speed it up and reduce costs
Automate business processes using AI to fix existing issues in business (including demographic change), speed them up and reduce costs
As all issues and bottlenecks will be fixed thanks to AI, business can be scaled further

In short: AI will help to produce more, faster, and cheaper.

You are not left behind

Fri, 20 Feb 2026 00:00:00 +0000

You are not left behind

How often have you heard a phrase like “If you do not become highly proficient in AI/LLMs/Agentic AI now, you will be left behind!” in recent months? Probably more often than you were able (or willing) to count. And it does not stop there. If we do not immediately learn the stuff as advised by the person uttering such phrases, we will lose our jobs and never get a job again. Our existences will be destroyed. And this will be solely our fault because we did not listen and obey.

Forget technical debt

Fri, 30 Jan 2026 00:00:00 +0000

Forget technical debt

To be clear: I do not think we should actually forget technical debt. Also, this is not the nth post discussing if “debt” is an appropriate metaphor. I do not have a strong opinion regarding the metaphor. My point is rather that I realized in a recent discussion that in the end, it is not so much about technical debt but rather about something else, and I wanted to share the thought.

We default to addition

Fri, 09 Jan 2026 00:00:00 +0000

We default to addition

I wrote a lot about the staggering complexity in IT, its detrimental effects, and what we can and should do about it (see, e.g., my “Simplify!” blog series. I wrote about the embedding of the complexity problem in a bigger context in my “Responsible IT” blog series). I also identified several drivers that usually increase accidental complexity, i.e., complexity in the solution which not needed to solve the given problem (see the third and fourth post of my “Simplify!” blog series for a more detailed introduction to accidental complexity).

AI and the ironies of automation - Part 2

Fri, 12 Dec 2025 00:00:00 +0000

AI and the ironies of automation - Part 2

In the previous post, we discussed several observations, Lisanne Bainbridge made in her much-noticed paper “The ironies of automation”, she published in 1983 and what they mean for the current “white-collar” work automation attempts leveraging LLMs and AI agents based on LLMs, still requiring humans in the loop. We stopped at the end of the first chapter, “Introduction”, of the paper.

In this post, we will continue with the second chapter, “Approaches to solutions”, and see what we can learn there.

AI and the ironies of automation - Part 1

Fri, 21 Nov 2025 00:00:00 +0000

AI and the ironies of automation - Part 1

In 1983, Lisanne Bainbridge wrote the much-noticed paper “The ironies of automation”. Being a cognitive psychologist, she discussed some counter-intuitive effects of automation in her paper. She called those effects ironies and paradoxes, providing precise definitions for both terms:

Irony: combination of circumstances, the result of which is the direct opposite of what might be expected.

Paradox: seemingly absurd though perhaps really well-founded statement.

It is your fault if your application is down

Fri, 31 Oct 2025 00:00:00 +0000

It is your fault if your application is down

Recently, AWS experienced one of its rare partial outages. Its DynamoDB service experienced a disruption in the US-East-1 region that could be tracked down to a latent race condition in the DynamoDB DNS management system which caused the disruption. A comprehensive post-event summary describing the outage, its cause and the resulting effects can be found here.

I do not want to add yet another opinion what AWS should have done differently. Quite the opposite. The trigger ¹ was an extremely unlikely race condition that is exceptionally hard to spot when looking at the design and basically impossible to detect via testing. It was one of those surprises that nobody could anticipate and that only became clear in hindsight.

Solving the wrong problem

Fri, 10 Oct 2025 00:00:00 +0000

Solving the wrong problem

I think a lot about AI-assisted and AI-based coding. The first one is a human who writes code with more or less support of an AI solution. We see it all the time already now. The second one is a human leaving the coding part to a fleet of AI agents. If the human does not even look into the code created but treats it as a black box and looks at the solution only from the outside, i.e., only watches what it is doing, it is usually called vibe coding.

The process deadlock

Fri, 19 Sep 2025 00:00:00 +0000

The process deadlock

When a company is small and young, work is often done in a seemingly ad hoc fashion. People briefly discuss and then do what appears to be the best solution for the task at hand. As the company is small and most people in the company have a good idea what is important and what is not, this approach tends to work quite well. Sometimes, a wrong decision may be made but in general, this sort of ad hoc approach works quite well.

A note about eventual consistency - Part 2

Fri, 29 Aug 2025 00:00:00 +0000

A note about eventual consistency - Part 2

In the previous post we discussed what eventual consistency actually means and why we sometimes need to favor eventual consistency over strong consistency. We also saw that most of the time we will not perceive any differences between eventual and strong consistency if set up properly. The differences only become apparent if the system encounters adverse conditions like, e.g., a network partition, loss of a node, or alike.

A note about eventual consistency - Part 1

Fri, 08 Aug 2025 00:00:00 +0000

A note about eventual consistency - Part 1

Recently I saw a skeet on Bluesky:

“Eventually consistent mainly means it will be regularly non consistent at all.”

I deliberately leave out the link to the post because I do not have the faintest idea regarding the context and motivation that made the author write that skeet and I do not want to make any assumptions about it. The author could have meant a lot of things.

Thoughts on AI and software development - Part 5

Fri, 18 Jul 2025 00:00:00 +0000

Thoughts on AI and software development - Part 5

In the previous post, we completed our analysis of the projection Steve made by looking at some unresolved side effects and questions that would come with such a future.

In this final post of this series, we will look at how we can hedge our options with such a scenario on the possible horizon and maybe tweak it a bit in our favor. Finally, I will wrap up with a few thoughts on how to deal with such sometimes grim and discomforting looking developments.

Thoughts on AI and software development - Part 4

Fri, 27 Jun 2025 00:00:00 +0000

Thoughts on AI and software development - Part 4

In the previous post, we looked at the likely short- and mid-term consequences if Steve’s projection should become reality. We saw a bit disturbed that most likely the only winners of that projection would be the providers of agentic AI solutions and their investors while everyone else would be on the loser side of the game.

In this post, we will complete our analysis by looking at some side effects and unresolved questions that would come with such a future.

Thoughts on AI and software development - Part 3

Fri, 06 Jun 2025 00:00:00 +0000

Thoughts on AI and software development - Part 3

In the previous post, we looked at the want side regarding Steve’s projection and the forces they trigger. We took off the rose-colored glasses and tried to have an unembellished look at these forces even if the things we saw, were a bit more gloomy and controversial than we would have liked it.

In this post, we will continue our analysis by looking at the likely short- and mid-term consequences of such a future becoming reality – also without any sugar coating.

Thoughts on AI and software development - Part 2

Fri, 16 May 2025 00:00:00 +0000

Thoughts on AI and software development - Part 2

In the previous post, we looked at Steve Yegge’s post where he made a projection from the vibe coding of today to controlling AI agent fleets in the near future that take over all coding reliably. Pondering this projection as a possible future, we realized that this future is not what we need as our actual problems in software development do not lie in a lack of developer productivity (or to be more precise: developer efficiency) but somewhere else.

Thoughts on AI and software development - Part 1

Fri, 25 Apr 2025 00:00:00 +0000

Thoughts on AI and software development - Part 1

This blog series will be a bit different. It might leave you with more questions than answers and I apologize for that upfront. It is also more controversial than most other posts, I have written before. In this post, I will discuss the current developments regarding AI in software development more from a CTO’s perspective. This means, I cannot simply reason about the pros and cons of a topic but I also need to take the market forces into account.

(Un)coupling in distributed systems - Part 2

Fri, 04 Apr 2025 00:00:00 +0000

(Un)coupling in distributed systems - Part 2

In the previous post, we started to discuss a specific type of coupling, the coupling between processes in a distributed system. We discussed the fallacy that loose technical coupling, i.e., using a message-based communication style is sufficient to ensure loose coupling between processes. We learnt that instead we need to implement loose coupling at a technical and a functional level to actually become loosely coupled.

(Un)coupling in distributed systems - Part 1

Fri, 14 Mar 2025 00:00:00 +0000

(Un)coupling in distributed systems - Part 1

Coupling is a big issue in software design. With software landscapes becoming more and more complex, coupling painfully steps on our toes whenever we attempt to change things. Hence, we want to reduce coupling. On the other hand, without any coupling systems and their parts would not be able to interact. Hence, we need coupling – feels a bit like being stuck between a rock and a hard place.

The long way towards resilience - Part 10

Fri, 21 Feb 2025 00:00:00 +0000

The long and winding road towards resilience - Part 10

In the previous post, we discussed what we find at the peak of Mt. Resilience, the peak of advanced resilience (anti-fragility).

In this post, we discuss the final question left, which is if we always need to climb to the top or if it is okay to stop our journey at one of the interim plateaus.

All models are wrong …

Before we dive into the question, let me repeat a statement first, i made quite at the beginning of this blog series:

The long way towards resilience - Part 9

Fri, 31 Jan 2025 00:00:00 +0000

The long and winding road towards resilience - Part 9

In the previous post, we broadened our view and learned about the sameness of business and IT. We also used the four response types of resilience to change our static approach regarding threats towards a more dynamic one, including continuous evaluation of threats, learning and repositioning in an ever-changing threat landscape. This adds the last missing shard to resilience: Anti-fragility.

In this post, we will discuss what we find at the peak of Mt. Resilience, the peak of advanced resilience (anti-fragility).

The long way towards resilience - Part 8

Fri, 10 Jan 2025 00:00:00 +0000

The long and winding road towards resilience - Part 8

In the previous post, we discussed what we find at the high-plateau of basic resilience.

In this post, we will discuss what is still missing to continue our journey to the top of Mt. Resilience. While discussing the missing ingredient, we will also broaden our view once more and find a familiar obstacle on our way.

Let us get started.

Standing still

As we have discussed in the previous post, we achieved resilience at the high-plateau of basic resilience, i.e., the ability to successfully cope with expected and unexpected adverse events and situations. We also saw we still lack the ability to evolve, to reposition ourselves in the face of a changing threats surface (with “threats” meaning adverse events and situations, see clarification in the next section).

The long way towards resilience - Part 7

Fri, 13 Dec 2024 00:00:00 +0000

The long and winding road towards resilience - Part 7

In the previous post, we discussed what it means to also prepare for surprises, the realizations needed to guide us to the next plateau, including the probably biggest obstacle in our way: efficiency obsession.

In this post, we will discuss what we find at the third plateau, the high-plateau of basic resilience.

The high-plateau of basic resilience

The high-plateau of basic resilience is the third interim stop, companies tend to reach on their journey towards resilience.

The long way towards resilience - Part 6

Fri, 22 Nov 2024 00:00:00 +0000

The long and winding road towards resilience - Part 6

In the previous post, we discussed the plateau of robustness, the second interim stop on the journey towards resilience, what it is good for, what its limitations are and what it means to get there.

In this post, we will discuss what it means also to prepare for surprises, the additional realizations needed to guide us to the next plateau – and we will meet the probably biggest obstacle on our way.

The long way towards resilience - Part 5

Fri, 01 Nov 2024 00:00:00 +0000

The long and winding road towards resilience - Part 5

In the previous post, we discussed discussed the 100% availability trap and revisited availability. We also discussed the two realizations needed to continue our journey to the second plateau.

In this post, we will discuss what we find at the second plateau, the plateau of robustness.

The plateau of robustness

The plateau of robustness ¹ is the second interim stop, companies tend to reach on their journey towards resilience.

The long way towards resilience - Part 4

Fri, 11 Oct 2024 00:00:00 +0000

The long and winding road towards resilience - Part 4

In the previous post, we discussed the plateau of stability, the first interim stop on the journey towards resilience – what it is good for, what its limitations are and why it is quite popular.

In this post, we will discuss the 100% availability trap, I introduced at the end of the previous post, in more detail and revisit availability. We will also discuss the realizations needed to continue the journey to the next plateau.

The long way towards resilience - Part 3

Fri, 20 Sep 2024 00:00:00 +0000

The long and winding road towards resilience - Part 3

In the previous post, we discussed the valley of feature-completeness, the starting point of our prototypical journey towards resilience and we realized that such a setup usually is not advisable anymore.

In this post, we will discuss why we still see such a setup quite often in companies even if it is not suitable anymore with respect to the demands of today’s IT system landscapes. Then we will discuss which realization is needed to kick off the journey and what we will find at the first plateau.

The long way towards resilience - Part 2

Fri, 30 Aug 2024 00:00:00 +0000

The long and winding road towards resilience - Part 2

We laid the foundations for our journey towards resilience in the previous post by clarifying what resilience is. We needed to do this to create a common goal for our journey.

In this post, we will discuss the starting point of our journey and why it is not sensible anymore to linger there.

Note that I will describe a prototypical journey of a company from zero to resilience. The starting point and the interim stops are states I have seen several times on my own. Nevertheless, this is a simplified model, which means that the journey of your particular company might be different.

The long way towards resilience - Part 1

Fri, 09 Aug 2024 00:00:00 +0000

The long and winding road towards resilience - Part 1

In its core, this post series will discuss three questions:

What is resilience?
How can we become resilient?
Do we always need to go the full 9 yards?

While the second question probably immediately makes sense to you, the first and third question may make you wonder. Is it not obvious what resilience is? And is there any alternative than doing everything needed if we want to become resilient? Based on my observations there is a lot of confusion regarding resilience. Almost everybody I talk to means something different if they talk about resilience.

Projects considered harmful - Part 2

Fri, 19 Jul 2024 00:00:00 +0000

Projects considered harmful - Part 2

In the previous post, we discussed how the broken feedback loops that software development projects create lead to a continuously deteriorating IT system landscape, resulting in an ever-shrinking dependability – which is probably the by far most important runtime property of software.

In this post, we will discuss the other three reasons why I consider projects harmful:

Due to the project blinders effect, local optimizations are enforced, leading to a complexity explosion of the related IT system landscape.
Software engineers, doing the actual work are tossed around from project to project which is problematic in terms of individual motivation and performance as well as in terms of team dynamics – both leading to suboptimal results, compromising the quality of the related IT system landscape.
If everything needs to be a project, if nothing can be accomplished without setting up a project, the regular organizational structure is completely inadequate. Instead of setting up more projects, the regular organizational structure needs to be fixed.

Finally, we will summarize our findings. Let us get started …

Projects considered harmful - Part 1

Fri, 28 Jun 2024 00:00:00 +0000

Projects considered harmful - Part 1

What is a project?

Lots of fancy definitions of the term “project” exist but in its core, it boils down to this:

A project is a temporary work structure set up to accomplish a particular task.

We take people from their regular organizational structures, group them together in a project team, give them a task and usually also a project organizational and process structure. Besides the deliverable, the task usually also contains a set of constraints, most commonly time and budget constraints.

Responsible IT - Part 2

Fri, 07 Jun 2024 00:00:00 +0000

Responsible IT - Part 2

In the previous post, we discussed the biggest challenges, IT organizations face these days. We have seen four big challenges, each with its own peculiarities:

Post-industrial markets and the resulting decision uncertainty (which equally affects IT due to the consequences of digital transformation).
Digital transformation and its consequences, the fact that business and IT have become inseparable and especially the indispensability of IT.
Highly complex, highly diverse and outdated IT system landscapes, held together with lots of duct tape and kept running which WD-40 all over the place.
Demographic change and the resulting skills shortage (which is a big issue at least for the Western hemisphere).

In this post, we look at the typical response patterns, why they usually only reinforce the problems and then try to rethink the solution space from first principles.

Responsible IT - Part 1

Fri, 17 May 2024 00:00:00 +0000

Responsible IT - Part 1

Lately, I attended an IT decision maker conference. A few hundred CIOs and other IT decision makers under a single roof. When looking at the conference schedule, you found the usual suspects:

Lots of talks about AI, especially GenAI
Quite some talks about modernization of IT and digital transformation ((mis-)using digital transformation as a synonym for IT modernization)
Some talks about cloud migration and platforms, complementing the previous topic
A few talks about data, data quality, green IT and security
A tiny amount of talks about low code and digital sovereignty
All that garnished with two or three talks about diversity and ethics, especially regarding AI

Up to this point nothing surprising. But when talking to some of those decision makers and trying to understand what really moves them, a much more interesting picture started to unfold:

The need-vs-want dilemma

Fri, 26 Apr 2024 00:00:00 +0000

The need-vs-want dilemma

In the The Calvin and Hobbes Tenth Anniversary Book, author Bill Watterson commented on some selected comic strips. Especially one comment made a lasting impression on me:

[…] I don’t know that there’s any connection between what we need and what we like.

Watterson made this comment in the context of a strip where Calvin, the 6 year old precocious and sometimes annoying main character presented a “poll of six-year-olds in this household” to his dad, trying to influence his father’s policies. Of course, the strip and Watterson’s comment on it were a skit on politicians who align their messages and their acting with the results of polls – which reflect what people want and not what they need.

Software - It's not what you think it is - Part 7

Fri, 05 Apr 2024 00:00:00 +0000

Software - It’s not what you think it is - Part 7

In the previous post, we summed up the misconceptions we discussed in this series and what they mean for the current discussion if AI solutions will replace software developers.

In this final post of this blog series, we will discuss what the misconceptions mean for the humans affected by them and how we could possibly improve the situation. Let us dive in.

Software - It's not what you think it is - Part 6

Fri, 15 Mar 2024 00:00:00 +0000

Software - It’s not what you think it is - Part 6

In the previous post we have discussed that software is invisible which deprives humans from an essential reasoning instrument. We have also looked at the malleability curse, the property of software that it can be bent and twisted in totally absurd and nonsensical ways while still working in some way.

In this post, we will summarize the findings from all previous posts of this series and discuss what it means for us and how we could improve the situation – with a focus on AI solutions in this post and the humans involved in the next and final post.

Software - It's not what you think it is - Part 5

Fri, 23 Feb 2024 00:00:00 +0000

Software - It’s not what you think it is - Part 5

In the previous post, we discussed the value preservation dilemma of software. We have seen that software – opposed to almost all physical goods – needs to be changed and adapted to the ever-changing needs and demands of its environment to preserve its value.

In this post, we will look at the final two issues of software I would like to discuss in this blog series, the invisibility dilemma and the malleability curse. Let us start with the invisibility dilemma.

Software - It's not what you think it is - Part 4

Fri, 02 Feb 2024 00:00:00 +0000

Software - It’s not what you think it is - Part 4

In the previous post of this blog series we discussed the greenfield fallacy and its consequences. In this post we will discuss the next misconception, the value preservation dilemma and its consequences. Let us get started.

The value preservation dilemma

Many misconceptions regarding software stem from comparisons with physical products like, e.g., cars or houses. We already discussed the assembly line fallacy in the first post of this series. The value preservation dilemma also has its roots in these broken comparisons.

Software - It's not what you think it is - Part 3

Fri, 12 Jan 2024 00:00:00 +0000

Software - It’s not what you think it is - Part 3

In the previous post of this blog series we discussed the broken abstraction dilemma, that abstractions help to create concise descriptions but take away degrees of freedom, and that breaking an abstraction usually means increasing the required size of the description by orders of magnitude.

In this post, we will first discuss what the broken abstraction dilemma means for AI solutions before moving on to the greenfield fallacy. Let us get started.

Software - It's not what you think it is - Part 2

Fri, 22 Dec 2023 00:00:00 +0000

Software - It’s not what you think it is - Part 2

In the previous post of this blog series we discussed the assembly line fallacy, the misconception that software development is the same as building a car and learned that software development is part of the design, not the construction.

In this post, we will discuss the next misconception, the broken abstraction dilemma and its consequences. This is particularly relevant for the concept of AI solutions writing software based on the input of business experts. Let us get started.

Software - It's not what you think it is - Part 1

Fri, 01 Dec 2023 00:00:00 +0000

Software - It’s not what you think it is - Part 1

The current AI hype is accompanied with a lot of predictions that software development will be taken over by AI solutions soon and most software developers will lose their jobs together with most other white collar workers. While I agree that AI solutions will have a significant impact on software development, I disagree with the notion that software development will be taken over by AI solutions anytime soon.

Back to the future

Fri, 10 Nov 2023 00:00:00 +0000

Back to the future

Recently I tried to catch up with the recent developments in platform engineering when I experienced once more a just too familiar déjà vu feeling. During my research, I came across the following definition of platform engineering:

“Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application. An Internal Developer Platform (IDP) encompasses a variety of technologies and tools, integrated in a manner that reduces cognitive load on developers while retaining essential context and underlying technologies.” ¹

Rethinking job ads - Part 2

Fri, 20 Oct 2023 00:00:00 +0000

Rethinking job-ads - Part 2

In the first part of this two-part blog post, I explained why I think most job ads today are rather pointless and are not particularly helpful in finding the people you need. Then I discussed some pointers that lead the way towards better criteria for job ads and mapped them against the typical job ad of today.

In this second post, we will go a step further and look at how job ads could look like that reflect the actual needs of today better. We will also discuss what it means for the interview process because you cannot really separate the ads and the interview process. Finally, we will sum it all up.

Rethinking job ads - Part 1

Fri, 29 Sep 2023 00:00:00 +0000

Rethinking job-ads - Part 1

Sometimes I read through job ads and almost always they leave me a bit at a loss. They always ask in a checklist style for some traits and experiences that based on my experience are either rather pointless or not really essential. Or they ask for a very narrow hyper-specialized profile garnished with the usual “you should be team-minded” antidote which is even worse regarding today’s challenges.

Forget efficiency

Fri, 08 Sep 2023 00:00:00 +0000

Forget efficiency

Should we really forget efficiency? No. But we should postpone focusing on efficiency until we are effective.

Basically, the previous sentence is the summary of this blog post and maybe it sounds obvious at first reading. But based on my experiences it is not. The biggest problem we have (not only) in IT these days is a lack of effectiveness. And what do we do to solve this problem? We attempt to improve our efficiency – amplifying our problems instead of solving any of them.

ChatGPT already knows - Part 7

Fri, 18 Aug 2023 00:00:00 +0000

ChatGPT already knows - Part 7

In the previous post, we explored why we need to be a bit rebellious to take the road towards becoming a “full-range engineer”.

We have also discussed that it is not enough for our industry if software engineers change their positioning. Being sustainable (in its general meaning) in an increasingly complex, unpredictable and ambiguous world requires a different focus than the currently predominant one.

In this final post of the series, we will put everything together, we have discussed so far and sum it up.

ChatGPT already knows - Part 6

Fri, 04 Aug 2023 00:00:00 +0000

ChatGPT already knows - Part 6

In the previous post, we discussed what it needs to become a “full-range engineer” and have seen that this is quite different from what software engineers often strive for today. However, the idea of a full-range engineer is focused on creating more value in a highly complex, uncertain and ambiguous environment and thus also improving our value.

In this post, we will explore why we need to be a bit rebellious to take this road and discuss if a changed positioning of software engineers is sufficient for the future of our industry.

ChatGPT already knows - Part 5

Fri, 21 Jul 2023 00:00:00 +0000

ChatGPT already knows - Part 5

In the previous post, we examined how the omnipresent hyper-specialization in IT pushes software engineers into areas of human weaknesses and how nerd culture (involuntarily) reinforces the push. We also collected a little list of ideas how we can position ourselves as software engineers, aligned with humans strengths, preserving our value as software engineers in the face of modern AI solutions.

In this post, we will discuss the first 6 items from the list at the end of the previous post, what it needs to become a “full-range engineer” (and of cause explain what “full-range engineer” means).

ChatGPT already knows - Part 4

Fri, 07 Jul 2023 00:00:00 +0000

ChatGPT already knows - Part 4

In the previous post, we discussed what humans and AI solutions are (not) good at and have learned the strengths and weaknesses of humans and modern AI solutions basically complement each other. We have also seen that software engineers often do not leverage their human strengths. Instead, they often position themselves in ways that places them in direct competition with the strengths of AI solutions.

ChatGPT already knows - Part 3

Fri, 23 Jun 2023 00:00:00 +0000

ChatGPT already knows - Part 3

In the previous post, we discussed where we came from as an industry, where we currently are and what the job of a software engineer (should) comprise. We also saw that most software engineers only fulfill a small part of what the role actually comprises, leading to direct competition with modern AI solutions that most likely we will not win.

In this post, we will discuss what humans and AI solutions are (not) good at to get a better understanding how we can position ourselves in a more valuable way without competing with AI solutions.

ChatGPT already knows - Part 2

Fri, 09 Jun 2023 00:00:00 +0000

ChatGPT already knows - Part 2

In the previous post, we discussed that detail knowledge, one of the major differentiators in software engineering careers, ceases to be a differentiator due to the growing capabilities of modern AI solutions. Whatever relevant detail knowledge a software engineer can have, these tools also can have. We stopped with the question what is left to software engineers in such a changing landscape, how to preserve one’s value.

ChatGPT already knows - Part 1

Fri, 19 May 2023 00:00:00 +0000

ChatGPT already knows - Part 1

At the moment, we see a lot of discussions revolving ChatGPT and other modern AI tools like, e.g., GitHub Copilot. Many managers praise them as the new silver bullet to beat the (often self-made) skills shortage that will make software developers redundant while driving software development efficiency to unprecedented heights.

Most software engineers on the other hand do not get tired to assure each other that these tools are nothing but another productivity aid which is completely useless without the guidance of an experienced software engineer. Hence, basically nothing will change for them.

Let's (not) break up the monolith - Part 2

Fri, 28 Apr 2023 00:00:00 +0000

Let’s (not) break up the monolith - Part 2

In the previous post, we started with the observation that companies (still) want to break up their monoliths into microservices. If you ask them what they expect from this measure, they typically expect to cure the “big ball of mud” issue with microservices or to improve their time to market with them.

We then discussed that simply changing the runtime artifact style from monolith to microservice will not help with the “big ball of mud” issue because the actual problems lie in the organization, the processes and the people, but not in the technology – especially not in the runtime artifact style.

Let's (not) break up the monolith - Part 1

Fri, 07 Apr 2023 00:00:00 +0000

Let’s (not) break up the monolith - Part 1

Time and again clients approach my colleagues and me with the request that they want to break up their monolith into microservices and they ask us how to do this best. Apparently, they are convinced that breaking up the monolith into microservices will solve some big problems they had for a long time.

Often, they are not willing to discuss if the measure will help to solve the problem they think it will solve. They only want advice at the technical design and implementation level.

Reality check

Fri, 17 Mar 2023 00:00:00 +0000

Reality check

Recently, I had two experiences within a few days that made me think regarding system dependability. In both situations, the systems acted detached from their surrounding reality and thus became confusing or even annoying – even if it would have been easy for them to detect their reality detachment.

A train in the past

The first experience was in a train. I traveled from Munich to Cologne. As it happens sometimes in German ICE trains, the information displays had a hiccup at the beginning of the trip, i.e., they did not display any information. About 30 or 40 minutes later, the system worked again. Probably someone restarted it.

The tail at scale

Fri, 24 Feb 2023 00:00:00 +0000

The tail at scale

About a decade ago, Jeffrey Dean and Luiz André Barroso published their IMO great article “The tail at scale” in the Communications of the ACM ¹. The article dives into the topic of latency tail-tolerance.

I read the article several years ago and found it very interesting. Recently, I reread the article and was surprised, how many of the ideas and concepts described in the article I have forgotten since the first reading. Hence, I decided to capture the key ideas of the article, hoping that I will not forget them again – or at least having a quick way to look reread them.

Watch your time - Part 2

Fri, 03 Feb 2023 00:00:00 +0000

Watch your time - Part 2

In the previous post, we identified time as our most precious resource. We saw that we are always confronted with a lot of tasks and expectations of other people. We also discussed that quite some of them turn out not to have any value for us or other people we care about. I call such tasks time killers.

I then discussed egoistic time thieves as an example of time killers – including the distinction between time thieves and people you help to grow because not everyone reaching out to you automatically is a time thief.

Watch your time - Part 1

Fri, 13 Jan 2023 00:00:00 +0000

Watch your time - Part 1

This is my 100th blog post and the first post, I release in 2023. I would like to use this post to write about something more general for a change. I would like to write about time.

Not about time in general, its relativity or the problems with time in distributed systems. I would like to write about time as your most precious resource, as the only actual currency of your life.

Keeping the balance

Fri, 16 Dec 2022 00:00:00 +0000

Keeping the balance

In this last post before the end of the year 2022, I would like to discuss a bit more general topic. I would like to discuss the problems of extreme positions in IT, why they are so popular – and why they are so harmful.

Let me start with a statement, I sometimes tend to make:

Any moron can take an extreme position. But it takes real intelligence to work out a good compromise.

Towards greener requirements

Fri, 02 Dec 2022 00:00:00 +0000

Towards greener requirements

I did not yet write a lot about sustainability in this blog. However, I think it will become one of the mega-drivers of the upcoming years in IT. As a consequence, I think it is sensible to start pondering how to include sustainability into our daily work.

Like resilience, sustainability has a lot of facets and dimensions and will I lay them out in a future foundational blog post. All of these dimensions affect IT, resulting in better working conditions, better business agility, higher society value (i.e., customer value based on society needs) and a reduced ecological footprint, if done right.

People only change in pain - Part 2

Fri, 11 Nov 2022 00:00:00 +0000

People only change in pain - Part 2

In the previous post, I discussed that people tend to embrace change the more likely, the worse they experience their current situation or expect their future situation to become if they do not change.

I illustrated this irrational behavior and also introduced some reinforcing effects that tend to make change even more unlikely due to an inaccurate assessment of the current and future situation. In this post, I will dive deeper into these reinforcing effects and discuss the resulting effects.

People only change in pain - Part 1

Fri, 21 Oct 2022 00:00:00 +0000

People only change in pain - Part 1

In a previous post, I discussed that the decision process, if confronted with change, is not rational but rather a gut decision. I also briefly mentioned that people tend to embrace change the more willingly, the worse they experience their current situation (or the more they are afraid of negative future implications if they do not change now).

This irrational behavior has quite severe implications regarding most change initiatives we can observe in companies these days. Therefore, I would like to dig a bit deeper into this topic in this post and the next one.

The right dose of resilience

Fri, 30 Sep 2022 00:00:00 +0000

The right dose of resilience

We have discussed the business case for resilient software design in my previous post. Let us assume, you have a budget and you know which are the most critical business processes/capabilities/interactions (whatever term suits your needs best) you need to secure, i.e., make more resilient.

Now what?

Getting functional design right

Based on my experience, first you should revisit your functional design. You should assess how you sliced and decoupled the different application parts at a functional level because that determines how resilient your application can become. If your coupling at the functional level is tight, all technical measures including resilience patterns will not help.

The business case of resilient software design

Fri, 09 Sep 2022 00:00:00 +0000

The business case of resilient software design

The business case of resilience is a bit tricky. You find quite disparate forces at work: While some people tend to underrate the need and value of resilience a lot, other people find it hard to stop adding resilience measures. As so often, the sweet spot is somewhere in the middle.

Underspending

Let us start with people who have the tendency to put too little attention on resilience. Often, those people can be found at a not-so-technical decision maker level. Let us assume, you go to your manager asking for budget to make your application more resilient. A counterquestion in such a situation could be: “How much money will we earn with it?”

The missing ops-dev feedback loop

Fri, 19 Aug 2022 00:00:00 +0000

The missing ops-dev feedback loop

I recently had a short discussion with a Product Owner after a talk I gave about resilient software design. His question was: “How can I motivate developers to care more about resilience?”

I found it interesting that a Product Owner (PO) approached me with that question because quite often POs are only focused on feature delivery and thus keep developers from building more resilient applications. Here it was the other way round – kudos to this Product Owner!

The 100% availability trap

Fri, 29 Jul 2022 00:00:00 +0000

The 100% availability trap

I briefly mentioned the 100% availability trap in a prior post. As this misconception is so widespread, I decided to discuss it in more detail in this post.

A typical discussion

Let me start with two familiar situations. In the first situation, a developer, aware of the fact that she might experience some kind of failure accessing a remote system, reaches out to her product manager:

Developer: “How should the application respond if it cannot reach that other system due to a technical problem?”

Why we need resilient software design - Part 5

Fri, 15 Jul 2022 00:00:00 +0000

Why we need resilient software design - Part 5

In the previous post, we discussed why the imponderabilities of distributed systems will hit us at the application level and we cannot leave their handling to the operations teams as we did in the past.

In this final post of this little blog post series, we will first recapitulate what we have learned so far and then discuss what it all means with respect to resilient software design.

Why we need resilient software design - Part 4

Fri, 01 Jul 2022 00:00:00 +0000

Why we need resilient software design - Part 4

In the previous post, we discussed availability, and how more nodes and the effects of remote communication affect it negatively. We learned that failures in today’s distributed, highly interconnected system landscapes are unavoidable and that we need to embrace them if we want to create highly available solutions.

In this post, we will discuss why these failures will hit us at the application level for sure and why we cannot leave their handling to the operations teams as we did in the past.

Why we need resilient software design - Part 3

Fri, 17 Jun 2022 00:00:00 +0000

Why we need resilient software design - Part 3

In the previous post, we discussed what distributed systems mean in terms of failure modes that can occur and what their concrete consequences are regarding application behavior.

In this post, we will see that these failure modes are not some theoretic concept, but something very real, i.e., that the question is not if your systems will fail but when and how bad they will fail.

Why we need resilient software design - Part 2

Fri, 03 Jun 2022 00:00:00 +0000

Why we need resilient software design - Part 2

In the previous, introductory post why we need resilient software design, we discussed the stepwise journey from isolated monolithic applications to distributed system landscapes where applications continually communicate with each other. We also discussed that the number of peers involved continually grew (and still grows), while the update propagation duration expectations became shorter and the availability expectations went to “never down” at the same time.

Why we need resilient software design - Part 1

Fri, 20 May 2022 00:00:00 +0000

Why we need resilient software design - Part 1

In this post series, I will discuss what resilience means for IT systems and why resilient software design has become mandatory.

In one of my previous posts, I discussed why I think resilience has become the probably most important paradigm of the 21st century. Still, the examples used mostly were about people and organizations. Thus, you might ask yourself if resilience is also as relevant for IT system design.

Resilience vs. Fault tolerance

Fri, 06 May 2022 00:00:00 +0000

Resilience vs. Fault tolerance

In this post, I will discuss if there is a difference between resilience and fault tolerance when talking about IT systems.

In my previous post, I discussed why I think resilience has become the probably most important paradigm of the 21st century. Still, the examples I used were mostly about people and organizations and you might ask yourself if this “resilience thing” also applies to IT systems – or if it is just fault tolerance in disguise, using a new, fancier term.

Resilience

Fri, 22 Apr 2022 00:00:00 +0000

Resilience - A new paradigm for the 21st century

Resilience IMO is a huge topic. It has a broader scope than most people think and – even more important – it has become much more relevant for most of us than most people imagine. Thus, time to shed some light on this topic. Over the course of several posts in the future I will discuss several aspects of resilience. Of course, my main focus will still be IT. But in some places I will leave the boundaries of IT as this topic affects – and supports – us in many ways.

In search of a robust change model

Fri, 25 Mar 2022 00:00:00 +0000

In search of a robust change model

Change is hard.

But not for you, you might say. You embrace change.

Really?

If you think about it for a moment and are honest, probably you would admit that it depends. In some places you embrace change while in other places you dislike or even fight it.

Changed procedures require a lot of attention from the brain

We cannot be open to all kinds of change all the time. It would kill our productivity. Changing habits and routines requires slow thinking ¹. Slow thinking consumes a lot of energy and we can only think about so much in slow thinking mode. Therefore, we need a lot of habits and routines to get through our days successfully.

The public cloud revolution - Part 2

Fri, 11 Mar 2022 00:00:00 +0000

The public cloud revolution - Part 2

In the previous post we discussed the evolution of the public cloud offerings from their beginnings until around 2015, starting at the plain compute and storage level and working their way up to the PaaS level.

In this post, we will continue our cloud evolution journey and see how the evolution turned into a revolution.

Public cloud ~2017

The public cloud revolution - Part 1

Fri, 25 Feb 2022 00:00:00 +0000

The public cloud revolution - Part 1

Discussing with other people, I often realize that many of them have not yet understood how much of a revolution public cloud is. In my previous posts, I already discussed why I think cloud-ready is not a viable strategy and the disruption delay which also affects cloud computing. Here I would like to add a different perspective.

My claim is: Public cloud, used right, is a game changer on the business side.

Leaving the rat race - Part 6

Fri, 11 Feb 2022 00:00:00 +0000

Leaving the rat race - Part 6

In the previous post, I gave a few recommendations how to deal with the hype industry and leave the rat race.

In this final post of this little blog series, I will add a few ideas how to use your time in a more useful way, discuss a few risks and side effects of taking this road and sum up the whole series.

Using your time better

Let us assume the recommendations of the previous post will help you to leave the rat race. This will not only result in a lot less stress, but also in more spare time. This raises the question if there are options to use some of that time to learn something more useful. ¹

Leaving the rat race - Part 5

Fri, 28 Jan 2022 00:00:00 +0000

Leaving the rat race - Part 5

In the previous post we discussed the actual strengths of humans and how the FOMO ¹ cycle tends to play against it.

In this post, I will give a few recommendations how to deal with the hype industry and leave the rat race.

Recommendations

Constant FOMO does not feel good. And as we have seen, the constant flood of “innovation”

This means, for most people it would be advantageous to leave the rat race, to break out of the FOMO cycle.

Leaving the rat race - Part 4

Fri, 14 Jan 2022 00:00:00 +0000

Leaving the rat race - Part 4

In the previous post we discussed that most of the “innovation” hype is nothing but a distraction from our actual problems.

In this post, we will look at the actual strengths of humans and why the FOMO ¹ cycle tends to play against it.

Anti-patterns resulting from cognitive overload

I already described in the second post of my Simplify! blog series that people who feel overwhelmed by the amount of perceived “innovation” develop “survival patterns”, ways to deal with the situation, evading the FOMO cycle as good as possible.

Leaving the rat race - Part 3

Fri, 17 Dec 2021 00:00:00 +0000

Leaving the rat race - Part 3

In the previous post we discussed that we are by far not as “innovative” as we claim to be, that most of the innovation puffery comes from a hype industry, trying to lure and force people into buying their products and services.

In this post, we will discuss that most of the “innovation” hype is but distraction from our actual problems.

The distraction from the actual problems

If we take a critical look at all the “innovations” we are confronted with on a monthly, weekly, daily basis, we see that most of them promise to solve some of the enduring problems we have in IT for a long time:

Leaving the rat race - Part 2

Fri, 03 Dec 2021 00:00:00 +0000

Leaving the rat race - Part 2

In the previous post we discussed the omnipresent FOMO and the resulting feeling of continuously running a Red Queen’s race for many of the affected people. I also discussed that based on my observations this impression of such a continuous high “innovation” speed is mainly driven by an IT hype industry which benefits from people who are in a constant state of FOMO.

In this post, we will discuss if we are really as innovative as we claim to be.

Leaving the rat race - Part 1

Fri, 19 Nov 2021 00:00:00 +0000

Leaving the rat race - Part 1

Recently I got a comment in a brief Twitter discussion that really made me think. I emphasized I think, developers also need to have at least some understanding of the business problems they solve ¹. Besides quite some agreement, I also got the following comment (analogously, not literally): “Developers are so busy keeping their IT skills sharp. They do not have time to bother with anything else.”

The non-existence of ACID consistency - Part 4

Fri, 05 Nov 2021 00:00:00 +0000

The non-existence of ACID consistency - Part 4

In the previous post of this little blog series, we discussed the actual value of strong ACID-like consistency.

In this final post of the series, we will discuss why ACID is usually not what you think it is.

Be aware that “ACID” usually is not what you think it is

If people think about ACID transactions, they typically think in terms of serializability, the strongest transaction isolation level, the ANSI SQL standard defines.

The non-existence of ACID consistency - Part 3

Fri, 22 Oct 2021 00:00:00 +0000

The non-existence of ACID consistency - Part 3

In the previous post of this blog series, we discussed why the “strong consistency is needed for business reasons” requirement is void. In this post, we will discuss the actual value of strong ACID-like consistency.

The real value of ACID consistency

The previous post may have left the question: Are strong consistency and ACID transactions pointless?

The definite answer to that question is: No, not at all!

The non-existence of ACID consistency - Part 2

Fri, 08 Oct 2021 00:00:00 +0000

The non-existence of ACID consistency - Part 2

In the previous post of this blog series, we discussed why strong consistency across multiple distributed data nodes is a bad idea. In this post, we will discuss why the “strong consistency is needed for business reasons” requirement is void.

ACID consistency does not exist outside IT

If you explain why strong consistency across system boundaries is a bad idea, you often encounter the “but it is needed for business reasons” argument. There would be functional requirements why strong consistency across system boundaries is needed.

The non-existence of ACID consistency - Part 1

Fri, 24 Sep 2021 00:00:00 +0000

The non-existence of ACID consistency - Part 1

Well, of course ACID consistency exists – and it is a good thing that it exists. Thus, feel free to call the post title clickbait … ;)

My point here is that it should not exist as functional requirement. But putting all these nuances in the title would have resulted in an awfully long title. So, I decided to keep the title short and risk the accusation of clickbait in return.

The disruption delay

Fri, 10 Sep 2021 00:00:00 +0000

The disruption delay

This blog post is about an observation I made pondering the slow adoption rates of several technologies in IT that I consider being game changers. My claim is:

It takes about 20 years until a disruptive IT technology arrives at mainstream.

With “disruptive” I mean that the technology will significantly change the way we do or use IT.

E.g., Open Source Software (OSS) changed the way we do IT, i.e., we create, build and sometimes even run software differently. Yet, OSS did not change a lot how IT was used, i.e., which kinds of solutions we build with it. The World Wide Web (WWW) on the other hand massively changed the way, how IT is used. E.g., e-commerce would be unthinkable without the WWW. It also changed the way we do IT a bit, but the biggest impact was how it changed the way IT is used.

The limits of standardization

Fri, 27 Aug 2021 00:00:00 +0000

The limits of standardization

Standardization is a two-edged sword. It has a value, but it also comes at a price.

If you solely think in terms of efficiency, standardization is the holy grail for you:

You can leverage economics of scale, i.e., produce a single item at a lower price.
You may get required resources or licenses at a lower rate because you buy higher volumes (another effect of economies of scale).
You only have to design your processes and train your people once.
You can leverage the fact that only one options exists, e.g., by creating an automation around it and offering services at a higher abstraction level.
You can run and monitor more instances of the same with little effort added. At best the effort stays the same, no matter how many instances you run.
And so on …

The bottom line is: Standardization allows you to do more for less money – which is the primary goal of everyone who tries to maximize efficiency.

The non-functional-no-value trap

Fri, 13 Aug 2021 00:00:00 +0000

The non-functional-no-value trap

This post is about another “evergreen” in IT: The fallacy that only business features have business value.

You think this is not a fallacy? That only business features have business value?

Well, you are not the only one. I meet such persons quite often, especially if I work in an architectural context. There, the project managers (non-agile flavor) or product owners (agile flavor) often claim that non-functional requirements do not create business value and thus need to be prioritized down, postponed or dropped completely.

People are not resources

Fri, 30 Jul 2021 00:00:00 +0000

People are not resources

It is summer. Most people try to enjoy the weather (at least when there is weather to enjoy). They do not want to rack their minds pondering mind-bending ideas. Therefore, I decided to pick some imo relatively straightforward ideas from my blog topics backlog for the next few posts. I hope they will still contain some food for thought for you.

The first topic that I want to discuss in this post is sort of “evergreen”:

The industrialization of IT fallacy

Fri, 16 Jul 2021 00:00:00 +0000

The industrialization of IT fallacy

Probably you also heard it several times before. Someone comes along saying that IT is a young and immature domain. That we are not yet an engineering discipline. That the way we write code sucks: Slow, not enough throughput, error-prone, not easily repeatable.

Hence, we need to learn from other domains like car manufacturing or house building how to professionalize our domain, adopting their engineering experience. We need to implement more of the industrial practices of, e.g., car manufacturing in our software development process. We need to set up efficient software production assembly lines and make writing code as efficient as building a car. And so on.

Quality - The unknown entity - Part 4

Fri, 02 Jul 2021 00:00:00 +0000

Quality - The unknown entity - Part 4

This is the fourth and last post of a blog series discussing quality.

In the previous post we discussed that quality always lives in a larger context which affects the different quality attributes. We also discussed that thus we always need to discuss quality with respect to the given context.

In this final post of the blog series we will discuss that as a consequence of the previous observations quality needs to be balanced on multiple levels. We will also discuss that it temporarily can be okay to compromise quality to reach a more important goal. Finally, we will discuss that just looking at what you do not want (e.g., bugs) does not necessarily lead to quality.

Quality - The unknown entity - Part 3

Fri, 18 Jun 2021 00:00:00 +0000

Quality - The unknown entity - Part 3

This is the third post of a blog series discussing quality.

In the previous post we discussed that we need to make quality measurable to create the required shared understanding. We also discussed that many people do not understand how their demands affect quality (and how we need to help them). And we discussed that we need to deal with the fact that quality attributes can be conflicting.

Quality - The unknown entity - Part 2

Fri, 04 Jun 2021 00:00:00 +0000

Quality - The unknown entity - Part 2

This is the second post of a blog series discussing quality.

In the previous post we discussed that quality is subjective and that quality has many dimensions.

In this post we continue the discussion regarding relevant properties of quality. First, we discuss we need to make quality measurable ¹ to create the required shared understanding. Then, we discuss many people do not understand how their demands affect quality (and how we need to help them). Finally, we discuss quality attributes can conflict and how to deal with that.

Quality - The unknown entity - Part 1

Fri, 21 May 2021 00:00:00 +0000

Quality - The unknown entity - Part 1

Quality is the subject of countless discussions, e.g., with unsatisfied clients. ¹

I had the situation more than once that a client was not satisfied, that they felt their quality expectations for the software were not met. When I then went to the development team and asked them about quality, it often turned out that they did not understand the reproach. In their perception, quality was good.

The importance of comments - Part 3

Fri, 07 May 2021 00:00:00 +0000

The importance of comments - Part 3

This is the third and last post discussing the value of comments in code.

In the first post we discussed the problems of the widespread dogmatic “clean code” interpretation that you must not write any comments. We also discussed that we should not document the “how” as the code already does it.

In the second post we discussed the value of documenting “what” for the readers and users of the code.

The importance of comments - Part 2

Fri, 30 Apr 2021 00:00:00 +0000

The importance of comments - Part 2

This is the second post discussing the value of comments in code.

In this post we will continue the discussion by looking at how documenting the “what” of code can create a lot of value for the readers and users of the code.

The importance of comments - Part 1

Fri, 23 Apr 2021 00:00:00 +0000

The importance of comments - Part 1

I wrote about the importance of documentation a few weeks ago. In this post I will discuss a related, also controversially discussed topic: Comments.

As the discussion is too long for a single post, I decided to split it up in three posts. This post discusses the widespread, often dogmatic “clean code” comment confusion and why it is not useful. Additionally, the post discusses how to best (not) document the “how”.

Don't make me think!

Fri, 09 Apr 2021 00:00:00 +0000

Don’t make me think!

API design is a huge topic these days and you find a lot of information about how to design good APIs. Unfortunately, most of it is about tools or technology: Use Tool X for great APIs! Use technology Y and everything will be fine!

Admittedly, we need good tooling to get our job done efficiently. And it is tempting! Let us just add an annotation to that class – et voilà: We have exposed an API. Now let us just put that vendor’s API gateway in front of it for dealing with the cross-cutting magic like authentication, rate limiting, etc. and we are done. The next 5 story points from the backlog easily burnt down. Let’s sprint on!

The importance of documentation

Fri, 19 Mar 2021 00:00:00 +0000

The importance of documentation

Documentation – not only since the rise of Agile a controversially discussed topic in IT. On the one hand, we see a lot of demand for documentation by many parties. On the other hand nobody wants to create it.

The Agile documentation confusion

The rise of Agile then delivered the supposedly watertight argument for software developers who loathe to write documentation:

Working software over comprehensive documentation ¹

The cloud-ready fallacy

Fri, 05 Mar 2021 00:00:00 +0000

The cloud-ready fallacy

Lately, I had a discussion with an on-premises data center manager who claimed that public cloud does not leverage any cost advantages over on-premises computing. His numbers would even prove that public cloud is more expensive than the on-premises operations they offer.

His conclusion was that there is no need to use public cloud offerings at all. It would only make things more complicated, risky and expensive due to:

The limits of the Saga pattern

Fri, 19 Feb 2021 00:00:00 +0000

The limits of the Saga pattern

The Saga pattern has become quite popular in the context of microservices. While it basically is described correctly in the referenced source, most often I see a grave misunderstanding.

The typical narrative goes like: “If you have a transaction that spans multiple services and their databases, do not use distributed transactions. Use the Saga pattern instead: Call the affected services in a row – typically by using events for activity propagation. If a services fails to update its database, roll back the transaction by triggering compensating actions in the services that already ran their updates.”

The microservices fallacy - Part 11

Fri, 05 Feb 2021 00:00:00 +0000

The microservices fallacy - Part 11

This post complements the discussion of the previous posts with a few general complementing recommendations and concludes this blog post series.

In the previous post we discussed microliths as a second alternative to microservices. Additionally, we we discussed a few typical challenges that people often face after deciding for one of the three alternatives microservices, moduliths or microliths and how to respond to them.

This post complements the findings of the previous posts with several general recommendations.

The microservices fallacy - Part 10

Fri, 29 Jan 2021 00:00:00 +0000

The microservices fallacy - Part 10

In this post we take a look at microliths as an alternative to microservices.

In the previous post we discussed moduliths as a possible alternative to microservices, when it makes sense to go for them and what preconditions must be met to use them successfully.

In this post we will continue with the second alternative I want to discuss in more detail: Microliths. Additionally, we will look at some problems that you might face if you decide for one of the discussed styles and what you can do about it.

The microservices fallacy - Part 9

Fri, 22 Jan 2021 00:00:00 +0000

The microservices fallacy - Part 9

In this post we take a look at moduliths as an alternative to microservices.

In the previous post we started to make sense of what we have learned from this blog series so far. We discussed when microservices are a sensible choice and what other conditions must be met to harvest their benefits and not only experience their downsides.

We then started to discuss what to do if the required preconditions for microservices are not met, and I wrote that I will discuss two alternative architectural styles in more details. The first alternative are moduliths which are the topic of this post.

The microservices fallacy - Part 8

Fri, 15 Jan 2021 00:00:00 +0000

The microservices fallacy - Part 8

In this post we start to make sense of what we have discussed so far – when we should use microservices, when not to use them and what to do instead.

In the previous post we discussed the actual reasons that justify the use of microservices and drew an interim conclusion. In this post we take the basis we built so far and use it to discuss when to use microservices, when not to use them and what to do instead.

The microservices fallacy - Part 7

Fri, 08 Jan 2021 00:00:00 +0000

The microservices fallacy - Part 7

This post discusses actual reasons that justify the use of microservices.

I hope you had a good start in the new year 2021! After a two weeks break, we will continue the blog series regarding the fallacies of microservices (and what to do about it).

In the previous post we discussed the last fallacy from the list – that microservices make technology changes easier. In this post we move on and leave the fallacies behind. In this post we discuss actual reasons that justify the use of microservices and draw an interim conclusion.

The microservices fallacy - Part 6

Fri, 18 Dec 2020 00:00:00 +0000

The microservices fallacy - Part 6

This post discusses the fallacy that microservices make technology changes easier.

In the previous post we discussed the fallacy that microservices lead to better solution design. In this post we look at the last fallacy from the list – that microservices make technology changes easier.

Easier change of technology

The last fallacy I will discuss is that microservices make it easier to change technologies and to explore new technologies.

The microservices fallacy - Part 5

Fri, 11 Dec 2020 00:00:00 +0000

The microservices fallacy - Part 5

This post discusses the widespread fallacy that microservices lead to better solution design.

In the previous post we discussed two fallacies – that microservices improve reusability (and thus pay for themselves after a short while) and that microservices improve team autonomy. In this post we take a closer look at the fifth fallacy I want to discuss – that microservices lead to better solution design.

The microservices fallacy - Part 4

Fri, 04 Dec 2020 00:00:00 +0000

The microservices fallacy - Part 4

This post discusses two widespread fallacies – that microservices improve reusability (and thus pay for themselves after a short while) and that microservices improve team autonomy.

In the previous post of this series we discussed the fallacy that microservices lead to simpler solutions.

In this post we will first look at the reusability fallacy. As I already wrote a whole blog series about that topic, I keep the discussion short in this post. After that we will have a bit longer look at the fallacy that microservices improve team autonomy. But let us begin with the reusability topic.

The importance of resilience engineering

Fri, 27 Nov 2020 00:00:00 +0000

The importance of resilience engineering

There was a bigger outage at AWS this week, and of course media coverage was big again. E.g., “Amazon Web Services outage hobbles businesses”, titles the Washington Post, just to name one.

You can find a lot more media coverage. Yet, for me the interesting part was not the fact that AWS had one of its rare outages. It was the bottom line that most of the articles had: AWS had a partial outage and therefore companies using AWS were hobbled.

The microservices fallacy - Part 3

Fri, 20 Nov 2020 00:00:00 +0000

The microservices fallacy - Part 3

This post discusses the widespread fallacy that solutions become simpler with microservices.

In the previous post we discussed the fallacy that microservices are needed for scalability purposes. In this post we take a closer look at the second fallacy – that microservices lead to simpler solutions.

Simplicity

Another widespread justification of microservices is that they would be simpler than monoliths. This idea is rooted in the famous quote by James Lewis that a microservice should always be of a size that you can get your head wrapped around. In other words: A single person should be able to understand a single microservice as a whole.

The microservices fallacy - Part 2

Fri, 13 Nov 2020 00:00:00 +0000

The microservices fallacy - Part 2

This post discusses the widespread fallacy that microservices are needed to tackle scaling issues.

In the previous post we looked at the origins of microservices, how the hype started, and we listed the most widespread fallacies regarding microservices. In this post we take a closer look at the first fallacy – that microservices are needed for scalability.

Scalability

One of the most commonly used justifications for microservices is scalability: “We need microservices to scale our application dynamically.”

The microservices fallacy - Part 1

Fri, 06 Nov 2020 00:00:00 +0000

The microservices fallacy - Part 1

This is a blog series discussing the fallacies of microservices. It complements a talk I have given.

In this series I will start with a little motivation why I think we need to revisit microservices critically. Then I will have a look at the origins of microservices (which already reveals a lot about the common misconceptions).

After that I will go through the most widespread fallacies one by one, followed by actual reasons to use microservices. Based on that, I will provide a few recommendations when to use microservices, when not to use them and which alternative approaches to use instead. Finally, I will complement the series with a few general considerations.

The value of speed

Fri, 30 Oct 2020 00:00:00 +0000

The value of speed

The speed of the IT value chain often is a topic in discussions I have with decision makers. The common theme is: The IT value chain is too slow. We need to deliver faster.

But how fast do you need to become, is my question then. I tell them, that the best in class, e.g., Amazon deploy roughly twice per second. Of course that is the deployment rate of all their teams united, but also a single team usually deploys many times a day. Combined with an appropriate management of requirements this means lead times from an idea to production of a few hours, sometimes just minutes.

The purpose of architecture

Fri, 23 Oct 2020 00:00:00 +0000

The purpose of architecture

Software architecture is one of the things in software development that is important. At least that is what many people – especially software architects – claim: It is about the “important decisions”, the “decisions that are hard to change later”, and so on.

To be frank, doing architectural work myself for more than 25 years meanwhile, these statements always left me a bit unsatisfied. It always gave me a bit of a “We also do not know what architecture is about. Somehow we believe it is important and to secure our jobs we need to talk everybody else into believing they cannot do without us.” feeling.

Throwing things away

Fri, 16 Oct 2020 00:00:00 +0000

Throwing things away

This post sort of complements the “Simplify!” blog series as it also points towards the simplification of the IT landscape. Still, based on a different train of thought, I decided to make it an independent post.

“Removing code does not create value”

The problem starts with an essential fallacy: Removing code does not create business value.

Whenever decisions are made what tasks IT development budget will be spent on, the question is: “Does it create business value?” ¹

Simplify! - Introduction

Tue, 13 Oct 2020 00:00:00 +0000

Simplify! – Introduction

When I look around, I see two evolutions that in combination worry me a lot:

IT has become an indispensable part of everyday business and private life.
The complexity on the IT solution side grows all the time.

Therefore, I wrote a blog series that discusses this evolution, its effects and what we can do about it. ¹

The series consists of the following parts:

Part 1 – Software has become indispensable in our everyday business and private life. If the software does not work as intended, we have a problem. At the same time, complexity in IT explodes and we are drowning in ever-growing complexity in IT – a worrying combination.
Part 2 – The complexity explosion stresses affected people out. As a result they develop counter-productive “survival patterns”: Going for superficial knowledge. Hyper-specialization. Ignoring developments. Becoming “opinionated”. Giving up. Or burning out while trying to keep up. Those patterns lead to vicious self-reinforcing cycles that lead to even more complexity.
Part 3 – Complexity needs to be divided in essential and accidental complexity. Essential Complexity is inherent in, and the essence of, the problem (as seen by the users). Accidental Complexity is all the rest —- complexity with which the people affected would not have to deal in the ideal world. While we cannot eliminate essential complexity, we need to work hard to avoid accidental complexity.
Part 4 – We need to distinguish different kinds of accidental complexity: Due to unnecessary requirements not adding value to the solution. Due to overly complex platforms regarding the given problem. Due to a lack of adequate platform support regarding the given problem. Due to overly complex software regarding the given problem.
Part 5 – Accidental complexity on a market level. Old response patterns to changing market realities lead to a lot of accidental complexity. Many companies face post-industrial markets and try to address changed markets demands by intensifying old industrial response patterns.
Part 6 – Accidental complexity on a company level. Not understanding IT (especially its primary “material” software) and the role of IT today lead to a lot of accidental complexity, either by imposing counter-productive practices on IT or by blindly copying concepts from others without understanding them.
Part 7 & Part 8 – Accidental complexity on a project level. Degenerated budgeting and IT staffing processes. Inward-bound focus of the organization resulting in a loss of market focus. Neglecting uncertainty reinforcing the situation. “Agile” and “DevOps” cargo cults, reinforcing industrial practices in a new disguise. The “high utilization means more productivity” fallacy. Rigid project constraints for the wrong reasons. All these and more lead to increasing accidental complexity.
Part 9 – Technology explosion as the result of an ongoing, not yet completed technology evolution cycle. FOMO and the tendency to blindly copy concepts as reinforcing drivers. And so on. Massively increased accidental complexity as a result.
Part 10 & Part 11 – Accidental complexity on an architectural level. Unresolved design deficiencies. Black holes and strange attractors crippling evolution. Architecture narcissism leading to bloated designs. Neglecting the business domain and focusing on technology only, and vice versa. The habit of DIY, combined with misconceptions regarding OSS. Missing the technology evolution. All these and more lead to increasing accidental complexity.
Part 12 – Accidental complexity on an implementation level. Breaking existing designs. Going for implementation shortcuts. Design by Stack Overflow. Show-off implementation. Keystroke theater. Quality theater. All these and more lead to increased accidental complexity.
Part 13 & Part 14 – An IT landscape consisting of layers of systems never cleaned up. Missing responsiveness of IT leading to solutions bypassing the IT department. Fear of decommissioning old systems. Missing the technology evolution and when to replace complex custom-built solutions. The “no-time to clean up” fallacy. The big clean-up initiative, trying to fix the existing mess “once and for all” with a single approach. All these and more lead to increasing accidental complexity.
Part 15 – Summing up and some general considerations. We need to simplify to survive in the long run. Some of the general recommendations do not only help in this context. Learn to do the right thing. Do not only focus on doing things right.

I have augmented this series with 3 posts about OSS, the first one discussing the rise and benefits of OSS, the second one discussing widespread misconceptions regarding OSS and the third one discussing the changed role of OSS in a cloud-native world.

Simplify! - Part 15

Fri, 09 Oct 2020 00:00:00 +0000

Simplify! – Part 15

Hooray! This is the last post of the “Simplify!” series. As I wrote before: I would never have expected that it would become that long. Initially, I expected 4, maybe 5 parts. Most likely I would not have dared to begin with it if I would have known. Anyway, we have arrived here – at last!

Before I add a few final considerations, let us briefly recap what we have discussed so far:

The continuous amnesia issue

Fri, 02 Oct 2020 00:00:00 +0000

The continuous amnesia issue

In this post I want to discuss an issue that I, being for a longer time in IT meanwhile, observe over and over again. It is the observation that as an industry we continuously forget what we have learned.

What do I mean with that claim?

The very first discussion – again and again and …

Probably I best illustrate this by sharing an experience I had. About two years ago I attended an unconference. It was not the first time I attended it. I liked it a lot. It always had a very energetic atmosphere. The participants were very active, loved to share and discuss. But unlike the previous times, I decided to do something different that year.

Simplify! - Part 14

Fri, 25 Sep 2020 00:00:00 +0000

Simplify! – Part 14

In the previous post, I discussed several relevant drivers that lead to ever-increasing complexity of the IT landscape, creating layers over layers of technology over time that never get cleaned up. As the post would have become too long otherwise, I left out the mitigation options.

This is the content of this post.

Improving the situation

As written in the previous post, there are certainly more drivers of ever-increasing IT landscape complexity, but the discussed ones are probably the most widespread and most harmful ones.

Simplify! - Part 13

Fri, 18 Sep 2020 00:00:00 +0000

Simplify! – Part 13

In the previous post, I discussed several drivers of accidental complexity on the implementation level and what we can do about it.

As announced there, I would like starting to discuss a final source of accidental complexity in this post, which are layers of technology that built up over time in an IT system landscape and never get cleaned up.

Based on my observations there are several drivers that support this source of accidental complexity. Here I will discuss the most popular and influential ones that I have observed.

Simplify! - Part 12

Fri, 11 Sep 2020 00:00:00 +0000

Simplify! – Part 12

In the previous post, I completed the consideration of accidental complexity at the architecture level by discussing potential countermeasures to the drivers of accidental complexity which I discussed in the post before.

When I started to discuss the different drivers of accidental complexity in IT and what we can do about it several posts ago, I wrote that I would move “from the outside in” to provide a bit of structure. In this post we finally reach the most inward level, the implementation level.

Simplify! - Part 11

Fri, 04 Sep 2020 00:00:00 +0000

Simplify! – Part 11

This post is about mitigation techniques regarding accidental complexity in the architectural level.

In the previous post, I discussed several relevant drivers on the architectural level that lead to increased accidental complexity of the IT landscape. As the post would have become too long otherwise, I left out the part what we can do about it.

The need for simplicity

But before I dive into the countermeasures, I would like to reemphasize why accidental complexity has become such a huge problem in IT. We already discussed some relevant problems in the first and second post of this blog series:

Simplify! - Part 10

Fri, 28 Aug 2020 00:00:00 +0000

Simplify! – Part 10

In the previous post, I discussed the technology explosion we could observe in the recent years, its drivers, how it often creates unneeded complexity, reinforcing drivers and what we can do about it.

I also mentioned that some widespread misconceptions regarding OSS (Open Source Software) act as a driver of accidental complexity. Therefore I inserted a little blog series discussing OSS, its rise, its benefits, the typical misconceptions and its role today to provide the required prerequisites for this post (and to keep its length acceptable).

The laws of architectural work

Fri, 21 Aug 2020 00:00:00 +0000

The laws of architectural work

After completing the short “OSS” blog series series and before returning to the “Simplify!” blog series that grew quite a lot while writing, I would like to discuss a completely different topic. I call it “the two first laws of architectural work”.

Of course, what I will describe are not actual laws. “Findings” or “lessons” (without the educational undertone) would be more accurate.

And even if they were laws, I do not know if they would be the first two ones. I just called them the first two ones to emphasize their relative importance. At least I find them very relevant as I see so many places where they are – often willfully – ignored which usually leads to negative consequences.

Open Source Software - Part 3

Fri, 14 Aug 2020 00:00:00 +0000

Open Source Software – Part 3

In the previous post, I discussed the two most widespread misconceptions about OSS, that OSS is for free and that it does not create any lock-in.

In this final post about OSS, we will discuss the role of OSS in the IT world of today and what it means for us.

A changing world

As I wrote in the first post of this series the triumph of OSS in IT mainly took place between approx. 1990 and 2015. But between 1990 and today a lot of things changed in IT. Especially the success of cloud technologies gave rise to a complete new breed of offerings: The managed services.

Open Source Software - Part 2

Fri, 07 Aug 2020 00:00:00 +0000

Open Source Software – Part 2

In the previous post, I discussed the rise of OSS, the positive effects it had and how it changed software development. At the end of the post I mentioned that also some misconceptions sneaked in. These I will discuss in this post.

Misconceptions sneaking in

While the rise and success of OSS was really important for the whole software development domain, it also fostered an “OSS is good, commercial software is evil” attitude and boosted a DIY (Do it yourself) attitude across developers. Note that creating a dichotomy “OSS vs. commercial” already is a misconception in itself ¹, but very often “OSS” still is misinterpreted as “strictly non-commercial” – including the misleading conclusions.

Open Source Software - Part 1

Fri, 31 Jul 2020 00:00:00 +0000

Open Source Software – Part 1

When I started to discuss accidental complexity on the architectural level in my “Simplify!” blog series, I quickly realized that I needed to discuss Open Source Software (OSS) first as it often acts as a driver of accidental complexity on the architectural level today.

So, I started to discuss OSS inside the post. While doing this, I quickly realized that OSS deserves a more detailed discussion than just a few paragraphs in a post about a different topic. Especially, as so often it is important to understand the past evolution of a topic – here OSS – to be able to assess today’s situation correctly.

Simplify! - Part 9

Fri, 24 Jul 2020 00:00:00 +0000

Simplify! – Part 9

With the previous post, we finished discussing the complexity drivers and mitigation options “above” the technology level. Starting with this post, we will discuss the technology level and “below”.

In this post, I will start with the technology evolution of the recent years and its implications. In the following posts, I will complement the discussion with some typical misconceptions regarding OSS (open source software), architecture narcissism and quality theater on the development level.

Simplify! - Part 8

Fri, 17 Jul 2020 00:00:00 +0000

Simplify! – Part 8

In the previous post of this series I started to discuss drivers on the project level that lead to accidental complexity regarding unnecessary requirements that do not add any value to the solution.

In this post, we will continue on the project level, but with a bit different focus. The topics of this post will be:

“Agile” and “DevOps” cargo cults, not improving anything
The “high utilization means more productivity” fallacy
Enterprise Architecture Management as an impediment
Compliance/governance implemented wrong adding accidental complexity

These topics do not directly affect the requirements, the platform or solution design, but they tend to create constraints that negatively affect projects in a way that leads to more accidental complexity.

Worlds apart

Fri, 10 Jul 2020 00:00:00 +0000

Worlds apart

A few days ago, I saw the following job advertisement creating a lot of mockery in the Internet:

While I perfectly understand why it received so many ironic comments, I think it goes deeper. Pondering the paradox of the job ad for a moment, I thought that it actually points out some much more fundamental problems. Thus, I decided to spontaneously interrupt my “Simplify!” blog series and insert this post.

Simplify! - Part 7

Fri, 03 Jul 2020 00:00:00 +0000

Simplify! – Part 7

In the previous post of this series I discussed some drivers on the company level that (among other things) cause a lot of accidental complexity in IT. The drivers were not understanding IT and its role today.

Together with not understanding post-industrial markets and digital transformation which I discussed before, they ultimately form the root cause for many other effects and evolutions, we will discuss in this and the subsequent posts.

Simplify! - Part 6

Fri, 26 Jun 2020 00:00:00 +0000

Simplify! – Part 6

In the previous post of this series, we looked at post-industrial markets and digital transformation as external market-based drivers that create pressure on companies and their IT departments. We also have seen how not understanding these drivers usually leads to counter-productive responses that ultimately make things worse instead better.

Especially, not understanding post-industrial markets and digital transformation is the root cause for many measures that we will discuss in the upcoming posts of this series. Those measures brought IT in the place where it is right now, being overly complex with lots of accidental complexity.

Simplify! - Part 5

Fri, 19 Jun 2020 00:00:00 +0000

Simplify! – Part 5

In the previous post, we looked at the different types of accidental complexity that help us to identify the places where to look for unnecessary complexity.

I also wrote that before starting this search, it first makes sense to understand better the origins of the current excessive complexity. How did it emerge? Understanding this evolution provides us with the final piece we need to understand before we can discuss countermeasures to simplify IT again.

Dismiss maturity models

Fri, 12 Jun 2020 00:00:00 +0000

Dismiss maturity models

I wanted to give you a short break from my “Simplify!” blog series. Well, admittedly, I also needed a little break … ;)

Therefore I will discuss a different topic in this post. The topic is the difference between maturity and capability models and why you should prefer the latter. ¹

Maturity models

Whenever improvement comes up, the next maturity model is just around the corner. E.g., the Wikipedia page for maturity models lists about 50 different maturity modes, around 15 for IT alone.

Simplify! - Part 4

Fri, 05 Jun 2020 00:00:00 +0000

Simplify! – Part 4

In the previous post, I discussed the difference between essential and accidental complexity. While we cannot avoid the essential complexity of a given problem, accidental complexity makes things unnecessarily harder without adding any value to the solution.

I stopped the post with the default theme that essential complexity is everything that comes from the problem side (a.k.a. the business domain). Whenever the solution complexity exceeds the problem complexity, that excess is accidental complexity added in the solution domain (a.k.a. in IT).

Simplify! - Part 3

Fri, 29 May 2020 00:00:00 +0000

Simplify! – Part 3

In the first post of this blog series, I described two antagonistic observations: IT has become an indispensable part of everyday business and private life while at the same time the complexity on the IT solution side grows all the time, meanwhile being on the verge of unmaintainability.

In the previous post, I discussed that the excessive complexity is extremely unhealthy for the people affected as well as for the companies they are working for. Additionally, I described that the “survival” patterns that the people apply to escape the stress induced by the complexity create a self-reinforcing loop that in the end makes things worse instead of creating a relief – especially if combined with constant efficiency pressure as it is normal for most companies.

Simplify! - Part 2

Fri, 22 May 2020 00:00:00 +0000

Simplify! – Part 2

In the previous post, I described two observations:

IT has become an indispensable part of everyday business and private life.
Complexity on the IT solution side grows all the time approaching the verge of unmaintainability.

In this post, I will dive a bit deeper. Analyzing the effects of this evolution on people and companies I will explain why it is an unhealthy and unsustainable evolution.

Effects of exploding complexity on people

Before understanding the effects of exploding complexity on companies, it is important to understand its on the affected people first. From what I see, most people – no matter if in development or in operations – feel overstrained with the current abundance of concepts, tools and technologies. It is already impossible to know all these topics and its variants just superficially, let alone in depth.

Simplify! - Part 1

Fri, 15 May 2020 00:00:00 +0000

Simplify! – Part 1

This little post series will be a bit different from the former ones as it discusses a relatively new train of thought of mine. Hence, in some places the reasoning may still feel a bit rough and not as thought out as in prior posts. If you should encounter such a place, please bear with me – and maybe help improving the reasoning via discussing the topic with me.

Degrees of uncertainty

Fri, 08 May 2020 00:00:00 +0000

Degrees of uncertainty

After introducing the concept of uncertainty as the unifying main driver of rethinking IT, I discussed the basic approach how to act under uncertainty in the previous post.

In this post, I will discuss that not everything is equally affected by uncertainty and how we need to respond differently to different levels of certainty and uncertainty.

From certainty to uncertainty

As I wrote before: Uncertainty is the unifying driver of rethinking IT and we need to rethink basically everything that we became used to in the last 50+ years in IT – and we often hold dear.

Acting under uncertainty

Fri, 01 May 2020 00:00:00 +0000

Acting under uncertainty

In the previous post, I introduced the concept of uncertainty as the unifying main driver of rethinking IT. I described how it breaks the certainty-based value prediction model that most of our acting (not only) in IT is based upon and why so many people and companies have difficulties to accept and adapt to uncertainty.

In this post, I will continue with discussing the basic approach how to act under uncertainty.

Understanding uncertainty

Fri, 24 Apr 2020 00:00:00 +0000

Understanding uncertainty

After a few posts discussing some aspects of software architecture, I would like to continue with the probably most important concept that I see in the world (not only) of IT today: uncertainty.

I already mentioned some of the most important drivers of uncertainty in previous posts, like the evolution of markets, the evolution of IT, the three waves of digital transformation and the different flavors of IT. Additionally, I mentioned complexity, another relevant driver of uncertainty in the posts about the evolution of IT and the different flavors of IT. ¹

The invisibility dilemma of software

Fri, 17 Apr 2020 00:00:00 +0000

The invisibility dilemma of software

In the previous post, I mentioned the second law of program evolution that Lehman described in his paper Programs, life cycles, and laws of software evolution

The law of increasing complexity

As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.

It was part of my explanation why I think, so-called “legacy systems” often are in a bad shape. Quite some of you probably noticed the “… unless work is done to maintain or reduce it” part of the law and wondered if I did not miss an important aspect in my discussion of legacy systems.

Legacy systems

Fri, 10 Apr 2020 00:00:00 +0000

Legacy systems

Last week I stumbled upon a nice quote from Corey Quinn that I shared via Twitter:

The reusability fallacy - Part 4

Fri, 03 Apr 2020 00:00:00 +0000

The reusability fallacy – Part 4

In the previous part of this series I discussed why reusability is a false friend in distributed systems and thus should not be used to sell distributed architectural approaches. Additionally, I discussed the difference between “usable” and “reusable” assets and why you should strive for “usability” in distributed approaches like, e.g., microservices.

In this final part of this little series, I will briefly summarize what we have discussed so far and then then give a few practical recommendations, when and where to strive for reusability, when to avoid it and what to do instead.

The reusability fallacy - Part 3

Fri, 27 Mar 2020 00:00:00 +0000

The reusability fallacy – Part 3

In the second part of this blog series about reusability I discussed the costs of making a software asset reusable. It turned out that creating an actually reusable asset means multiple times the costs and efforts compared to creating the same asset just for a single purpose.

Additionally, we have looked at asset properties that work as reusability promoters or inhibitors to understand which functionalities are worth being made reusable and which are not. It turned out that almost everything worth being made reusable already exists – typically as part of the programming language ecosystems or an OSS solution. On the other hand, the architectural paradigms that are usually sold with reusability as huge cost saver typically target the functional domains that offer little reuse potential.

The reusability fallacy - Part 2

Fri, 20 Mar 2020 00:00:00 +0000

The reusability fallacy – Part 2

In the first part of this blog series about reusability I discussed why all the reusability ideas break that root in the physical world and that are based on the idea you can save money in the production process by using reusable/standardized parts. We have seen that the actual production process in IT is already practically optimal. Thus, if reusability can help to save time, costs and efforts at all, it can only do so in the design process, which – as we have also seen – is everything until the last line of code is written.

The reusability fallacy - Part 1

Fri, 13 Mar 2020 00:00:00 +0000

The reusability fallacy – Part 1

After several posts discussing different aspects of IT as a whole, I would like to start discussing another thread of thinking: software architecture. This is a huge topic and I pondered for quite a while where to start. Finally, I decided to start with debunking the long-lived architectural myth of reusability because this makes it easier to understand some of the ideas that I will discuss in later posts.

The different flavors of IT - Part 2

Fri, 06 Mar 2020 00:00:00 +0000

The different flavors of IT – Part 2

In the last post, I described how different external drivers (pre-industrial, industrial, post-industrial) lead to different IT working modes and discussed their typical properties.

In this post, I will first add another complementing point of view that leads to a fourth working mode. Afterwards, I will briefly discuss how this model can also help to understand the lifecycle of IT-based business offerings better. Finally, I will show how this model can be generalized to different domains and the problems that arise if different working modes collide.

The different flavors of IT - Part 1

Fri, 28 Feb 2020 00:00:00 +0000

The different flavors of IT – Part 1

In a previous post, I discussed pre-industrial, industrial and post-industrial markets. It also helps to understand a lot of other developments and problems (not only) in the world of IT. In this post, I will discuss how it affects the IT working mode.

Different market situations typically result in different IT working modes, i.e., properties that an IT organization implements. As long as the IT working mode is in sync with the external drivers, everything is fine. If not, it leads to problems. But before discussing those problems, let us first look at the working modes.

The three waves of digital transformation

Fri, 21 Feb 2020 00:00:00 +0000

The three waves of digital transformation

“Digital transformation” is probably one of the most overstressed terms of the last years - not only in IT, but also everywhere else: in the news, the media, every conference, everywhere. You just cannot not escape it. But what makes it really annoying is that most people who talk about it do not seem to have any proper idea what it actually means.

One manager proudly announces that they are working on an electronic customer file and thus are a digital leader. The next one talks about their e-commerce strategy, the third one about their cloud strategy and yet another one about platforms and API economy. And of course all are self-proclaimed leaders of digital transformation.

Systems thinking and quality

Fri, 14 Feb 2020 00:00:00 +0000

Systems thinking and quality

A few days ago I rediscovered a short presentation that Dr. Russell Ackoff gave in 1994. The recording of this presentation was titled “If Russ Ackoff had given a TED talk…” on YouTube. The presentation is really short – just 12 minutes. But it contains a lot of wisdom, probably too much to understand it all at once.

I meanwhile watched the presentation several times and I am still not sure if I really got my head wrapped around all details. While the ideas and examples that Ackoff present feel simple and straightforward, I think it is surprisingly hard to really understand their consequences for our daily challenges. That’s why I decided to present and discuss them in this post – of course not claiming for myself that I completely understood what Russ Ackoff said.

The evolution of IT

Fri, 07 Feb 2020 00:00:00 +0000

The evolution of IT

In a former post, I briefly described the evolution of markets because it influences the IT of today a lot, including the confusion we often experience. In this post, I discuss the evolution of IT itself, as this is also relevant to understand the current state and role of IT.

Once upon a time

In the beginning (long before we started calling IT “IT”), there were tube-based computer (omitting the short phase of mechanical computers). They were relatively unreliable and maintenance intensive. Thus, they were not interesting for commercial use.

All models are wrong. Some are useful!

Fri, 31 Jan 2020 00:00:00 +0000

All models are wrong. Some are useful!

I work with models a lot. I use them to make real-world effects better comprehensible and thus enable pondering them. When sharing such a model with other people, every once in a while someone cites

All models are wrong, but some are useful. ¹

To be more precise: Usually, only the first part of the quote is cited. I do not want to speculate about the motivations of the persons who cite this quote. They will have their reasons. I mention the quote because from my point of view it is really useful to explain the power and the limitations of models.

The demise of business processes

Fri, 24 Jan 2020 00:00:00 +0000

The demise of business processes

Whenever you come to a client as an IT consultant, it will not take long before someone will start talking about business processes. A typical narration is like “That’s a nice idea. But we need to make sure that everything is aligned with our business processes”. This is not limited to IT projects. If you create a new product, if you touch the organization or change anything else: it needs to be aligned with the business processes. The whole company seems to revolve around their business processes.

The evolution of markets

Fri, 17 Jan 2020 00:00:00 +0000

The evolution of markets

While preparing a series of blog posts describing several of the ideas I worked on in the last years, I realized that many of the topics are interrelated. Quite a lot of the ideas reference the concepts of industrial and post-industrial markets. Thus, it is probably a good idea to start with those concepts.

If you ask yourself why I talk about markets in the context of IT, please just bear with me for a moment. The core properties of the markets influence IT more than most people would ever assume and many issues of today’s IT become apparent, once you have understood those properties and how they affect IT.