Recent content in Blog on Uwe Friedrichsen
The essence of architectural work - Part 5 In the previous post , we concluded the discussion of the Why , the purpose of architectural work, by looking at the cognitive and the humane facets of architectural work. We also briefly discussed that AI agents are not able to satisfy these traits of architectural work unless you solve solved problems time and again. In this post, we will move on to the…
The essence of architectural work - Part 4 In the previous post , we discussed the economic purpose of architecture. The economic purpose is probably the most emphasized facet regarding the Why of architectural work, yet hardest to grasp in its entirety and the hardest to get right. However, this does not mean that the other facets would be of less importance. But as they do not immediately…
The essence of architectural work - Part 3 In the previous post , we discussed several architectural anti-patterns. We have seen that we are a lot more vulnerable to them if we do not understand why we do architectural work, i.e., understand its purpose. We understood that the focus and thus value of architectural work is accidental without having a clear understanding of why we are doing it.…
The essence of architectural work - Part 2 In the previous post , we started discussing that not understanding why we do architectural work leads to many detrimental anti-patterns in software development. We can observe these patterns time and again: “Agile” architecture a.k.a. emergent architecture BDUF architecture Hype-driven architecture Tunnel-vision architecture One-size-fits-all…
The essence of architectural work - Part 1 This blog series is a long-overdue write-up of my presentation “Essential architectural work” . Of course, this is the 2026 version of the contents, i.e., it will also discuss the impact of AI on several aspects of architectural work. However, it is interesting to see that quite a bit of the stuff I discussed 7 years ago and learned over many…
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…
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…
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…
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…
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…
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,…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
(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…
(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…
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…
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…
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…
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…
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…
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 1 is…
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…
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…
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…
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…
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 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…
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…
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)…
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…
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.…
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…
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…
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…
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…
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.…
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…
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…
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…
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…