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.
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.
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.
In the previous post, we discussed what we find at the peak of Mt. Resilience, the peak of advanced resilience (anti-fragility).
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.
