Dot Connector. Cartographer of uncharted territory. Keeper of timeless wisdom. Translator between floors. North star explainer. Curious. Introvert. Works @ codecentric
@alexthurow @kevlin yup, all true, and all known for many years.
my point is that the predominant narrative inside and outside of IT is that our core problem is that our demand for software is much higher than our ability to produce it.
and "ability to produce it" usually is equated with "writing code".
you know that this is not our problem, kevlin knows it, i know it and some more people know it, too.
however, it does not change the narrative and the decision making processes based on it :|
@adrianco as you wrote: ai-based sw dev already covers a lot of what is required in average. this, plus the market mechanics brings me to the point that i need to dive deep into the hedging possibilities – at least in my role, advising my board regarding strategic options (for an IT service provider that leans heavily in software development) based on likely market developments.
overall: no contradiction to your implied counter argument. rather an attempt of a reasoning journey ... /e
@adrianco in this post, i looked at the market mechanics and concluded, we cannot rest on the fact that ai-based sw development does not solve our problems because decision making is not based on what we need but adheres to different forces.
in the next to posts, i will then ponder the consequences of all this and how to hedge your career options. /2
@adrianco if i try to do "business as usual", i think ai can do an awful lot of what is expected from any type of white collar worker in average, including sw devs.
my reasoning was a bit different: in the first post, i said (with reference to other posts that detail the claim) that our main challenges in sw dev are not a lack of efficiency (but a lack of effectiveness). i.e., we do not need ai-based sw dev to solve our actual issues. /1
i just released the 2nd post, pondering the idea of ai-based coding and its potential impact on software development. this time i discuss the forces that drive the market and decision making (warning: this post might feel a bit darker and more controversial as usual): https://www.ufried.com/blog/ai_and_software_development_2/
nevertheless, enjoy if you like ... ;)
This week, on 14th and 15th of May, I will be holding my talk „Thoughts on (Modern?) Software Development - Observations from a 20-years long journey“ at codecentric AG’s Frankfurt/Main tech&talk Meetup and at JUG Darmstadt.
For more details, see:
and:
https://onmoderndev.de/en/2025/05/12/talk-on-15-05-2025-at-jug-darmstadt
All my upcoming talks can be found at:
https://onmoderndev.de/en/2025/01/24/next-thoughts-talks-in-2025
Hope to see you there! 🤓 📚
🎥 SAG Expert Interview Series – Episode 12 is out now! 🥳
@ufried shares exclusive insights on building #ResilientSoftwareSystems – urging a shift from efficiency to simplicity, empathy, and purpose. He highlights GenAI's real value (and cost), and calls for #SustainableArchitecture over hype.
📌 Key Takeaways:
✅ Resilience as necessity, not luxury
✅ Effectiveness over pure efficiency
✅ Empathy as a key architecture skill
Watch the full interview 👉 t1p.de/6z19u
i have been interviewed about resilient software design at the #sag2024.
you may notice it was a quite spontaneous interview (at least for me): putting together the answers on the fly while talking in english was a tad challenging for me ... :)
anyway, enjoy if you like ... ;)
Sir David Attenborough: 99 today.
Happy Birthday!
A David Zinn robot 🤖 to start your day. I love it when he incorporates local features and nature into his drawings ...
you can find the (unabridged) slide deck of my "simplify! 10 ways to reduce complexity in software development" talk i gave at #jax2025 at https://speakerdeck.com/ufried/simplify-10-ways-to-reduce-complexity-in-software-development. enjoy if you like ... ;)
i started a new 4 part blog series, pondering a projection of vibe coding and its potential impact on software development, the need for it, the market drivers, the consequences and a lot more. part 1 sets the scene and discusses the need: https://www.ufried.com/blog/ai_and_software_development_1/
enjoy if you like ... ;)
i just released my 2nd (and last) post about (un)coupling in distributed systems, this time discussing the redundancy fallacy and temporal decoupling, including the additional design options it brings: https://www.ufried.com/blog/coupling_2/
enjoy if you like ... ;)
You know, we invented systems before there were computers.
'Forms' were on paper, rather than on screens.
An 'in tray' was an actual metal wire, or wooden tray, for paper letters, notes, memos and forms.
A database was called a 'filing cabinet'.
An 'interface' was a mail box.
A 'front end' was a person, with a job title like administrator, or clerk.
These systems were described, in excruciating detail, in procedure manuals.
The processes were run not by CPUs, but by people.
'Bugs' were when people made mistakes.
Systems were difficult to understand, even harder to diagnose, and very very hard to fix or change.
To change the way a department worked, for e.g. accounts receivable was so hard that most companies never even tried.
And yet somehow people are under the impression that it is the code that is the difficult bit about modern business systems.
So they try and make the code part easier.
#LowCode #LoCode #NoCode #AI #GenAI #LLM
It was never the code. Code was never the bottleneck.
i just released a new blog post (part 1 of 2) about (un)coupling in distributed systems and some of the misunderstandings often related to it, especially the misconception that using a message bus is enough to ensure loose coupling: https://www.ufried.com/blog/coupling_1/
enjoy if you like ... ;)
Guess it can't hurt to broadcast this once more: The NCSC, NIST and Microsoft all recommend organisations do not force regular password expiry.
https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry
"Regular password expiry is a common requirement in many security policies. However, in the Password Guidance published in 2015, we explicitly advised against it. This article explains why we made this (for many) unexpected recommendation, and why we think it’s the right way forward."
i just released the 10th and final part of my "long way towards resilience" blog series, this time discussing if we always need to go all the way to resilience or if it may be okay to stop earlier, plus a bit of summing up: https://www.ufried.com/blog/road_to_resilience_10/
enjoy if you like ... ;)
@jasongorman well, it is a useful organization if we need to do a complicated (not complex) task in a scaled way and decision time does not matter. so this was the most efficient setup for industrially scaled production in the early and mid 20th century.
however, the constraints are very different for most organizations today and we need very different types of organizations to thrive (decentralized, built around capabilities, ...) but it takes organizations *very* long to adapt, i am afraid...
„For me getting through the blog was like a fresh air. With such technology leaders as Uwe (he’s a CTO now) we can at least hope that in time our industry will become a better place to be.“
https://blog.daniel-ivanov.com/2025/01/25/tribute-to-the-blog-of-uwe-friedrichsen/
… well worded. I agree 🙂. Thanks, @ufried 🙏
@alexthurow thx! <bow>
