The law of conservation of energy states that the total energy of an isolated system remains constant. That is, without external input of some kind, energy can't be created or lost, it can only change state.
If you've designed software over the last fifteen years, likely you'll have come across the great microservices revolution. Advocates, reacting against giant and horrible-to-maintain monoliths, pushed for atomisation of concerns, creating instead an ecosystem of multiple small applications each dedicated to a single task.
There is a link here. Trust me.
The compelling argument for microservices is that each application is easier to understand, update, test, and maintain. In fact, since they are decoupled, you could have ten interacting microservices all written in completely different programming languages (although just because you can doesn't mean you should...). You reduce complexity in the overall system, and life is good.
Or is it?
Thing is, in a straight refactor the functionality hasn't changed - just how those elements communicate. Complexity in the individual applications has indeed gone down, but it hasn't vanished - it has been moved to your network calls and that can be a whole different world of pain to implement and debug.
Complexity in an isolated system remains constant.
Boom. Link.
Well, sort of. You can absolutely design out some complexity, but there is an irreducible lower bound, beyond which further gains are not removing complexity, but moving it somewhere else. This is actually Tesler's Law from the world of UX, which states that "for any system there is a certain amount of complexity which cannot be reduced".
And we're certainly not here to reignite an old discussion - for our purposes, the important point is that many advocates for microservices didn't seem to realise they had moved complexity, not eliminated it, and this implicit tradeoff surfaced somewhere later to bite them. The microservices / monolith war ended in a tetchy stalemate with macroservices, and everyone went back to shouting about tabs vs spaces.
This is 2026 - we're enlightened and stuff. So I guess we'd better talk about AI.
AI is a magic bullet - we can use it to do all our work, leaving us free to expand our minds by writing poetry or some other edifying pursuit. In system terms, we are taking the complexity and removing it from our lives using our agents. Right?
Of course not. Complexity doesn't go away.
Consider a situation where you are doing some research on something that has happened in your industry. Maybe someone has asked about the British Library ransomware attack from 2023? But oh no! You don't know anything about it. So you could crawl over the internet, reading lots of documents, press releases and news reports on the subject and bring all that knowledge together into a suitable writeup. Or... you could go to ChatGPT and type "please tell me about the British Library ransomware attack from 2023" (always say please - it's polite). Seconds later, you've got a page of information and have skipped that tedious research phase.
If this is low stakes, then fine - so what? It's likely to be good enough for a chat in the pub. If it's something you're being paid to do properly, then you have to think quality control. You know AI can hallucinate or (harder to spot) draw unrelated points together to make incorrect conclusions. So you need to fact check, but you don't know anything about this subject and whatever else it does, AI is very good at writing something that looks authoritative.
As anyone who reads my blog regularly knows, I'm not anti-AI and this is a solvable problem - through careful questioning of the AI, particularly anywhere something doesn't feel right, one can challenge the given output and catch some errors. You can ask it to provide sources - which you can then go and read for yourself. This extra diligence might well be enough for your purposes - the point is that there is a whole, detailed QA and post hoc validation step which you've had to introduce to compensate for your first change.
Is this still faster? Quite possibly, but it's a tradeoff. Complexity has moved in the system - AI has moved complexity from production to assurance. To call back to the above point about microservices, the important thing is to recognise where the complexity has moved to and actively consider the tradeoff in your context.
So what about process automation? Ideally this is somewhere you hand business complexity to a computer and take a step back. However, AI systems by themselves are inherently unreliable - by this, I mean you cannot guarantee the output. If you've automated a process using a traditional algorithm, you have to worry about the data going in, but you can control the state and the output should be 100% consistent. AI does not give you that guarantee. With AI, you may ask the same question 10 times and get 10 variations on the answer. You might get one answer which is just wrong and if you're using this kind of system, you have to plan for that output.
This means instead of designing a system to be consistently right (traditional algorithm), you have to accept you're going to get some incorrect results and have processes to identify this, and processes to resolve problems when incorrect results slip through. You have to design for wrongness. In many organisations, this is a cultural shift as well as additional processes and this is not an easy thing to accomplish. Even harder, the org can adopt the mindset of fault tolerance - eg 0.1% of transactions are just going to be wrong and this is the tradeoff for the extra speed - but I'd argue this is another much bigger step for most organisations who don't have some kind of manufacturing / Six Sigma mindset baked into their DNA.
So closing, what is the point? If you're attempting to remove complexity from a system, you need to look very carefully at the impacts of your change. There are gains to be made, but when something appears to remove complexity, you have to ask where the complexity went - and who now owns it. There is a good chance you've dropped it on someone else's shoulders. Understand your tradeoffs.
No comments:
Post a Comment