Brittleness and incremental improvement
Every system — computer or otherwise — needs to deal with possibilities of damage or error. If it does this well, it may be regarded as “robust”, “mature(d), “strengthened”, or simply “improved”.* Otherwise, it can reasonably be called “brittle”.
*It’s also common to use the word “harden(ed)”. But I think that’s a poor choice, as brittle things are often also hard.
0. As a general rule in IT:
- New technologies and products are brittle.
- They are strengthened incrementally over time.
There are many categories of IT strengthening. Two of the broadest are:
- Bug-fixing.
- Bottleneck Whack-A-Mole.
1. One of my more popular posts stated:
Developing a good DBMS requires 5-7 years and tens of millions of dollars.
The reasons I gave all spoke to brittleness/strengthening, most obviously in:
Those minor edge cases in which your Version 1 product works poorly aren’t minor after all.
Similar things are true for other kinds of “platform software” or distributed systems.
2. The UI brittleness/improvement story starts similarly:
- Graphical user interfaces can present users’ choices clearly, making them great antidotes to users’ initial lack of system knowledge or training.
- Usability testing and engineering can lead to improvements and the removal of glitches.
Unfortunately, however, as systems add or change features, UI navigation can get more difficult over time rather than easier.
In at least one scenario — plane crashes due to confused-pilot error — the consequences can be literally fatal.
3. Sometimes brittleness just doesn’t get solved.
- Security is perhaps the most visible example. Almost every security system can be broken, and bad actors actively do so.
- Another example was 1980s-90s CASE (Computer-Aided Software Engineering), specifically in the area of generating code from specifications. The technology was only able to generate apps that performed a limited set of functions — too limited to be useful outside of certain niches — and never successfully evolved further.
4. Large organizations are riddled with screw-ups. One of the most successful large enterprises in world history was the US military of World War 2 — and that is literally the organization where the word snafu was coined.
The response is often bureaucracy. Somebody makes a mistake; procedures and rules are then instituted to ensure the mistake is never repeated. Over time, many rules and procedures build up, until organizational systems are hardened. Business processes wind up taking many steps, each of which represents both a cost and a potential for failure. And sometimes the only decisions that successfully get through the process are uninspired, uncreative or flat-out wrong.
This is the classic example of “hardening” — commonly expressed via its rough synonym “calcification” — adding even more brittleness than it removes.
Outward-facing/regulatory bureaucracies can be even worse..
- Regulators generally have two constituencies — consumers/general public and businesses — with the benefits of regulation going to one and the costs going to the other. Anything regulators do will likely displease at least one constituency.
- These ever-unsatisfactory regulations can often only be changed through a long administrative or legislative process.
- Violating regulations has unpredictable but sometimes severe consequences.
The whole thing is a colossal mess.
5. Many of the previous points apply to enterprise applications, which facilitate business processes, have UIs, and commonly involve platform-like technology as well.
Changing enterprise apps can take both discontinuous and incremental forms; you can either replace your old apps outright or change something in (or in the implementation of) the ones you have.
- If you rip-and-replace your apps, you’re likely to also do so to your business processes, and vice-versa. Discontinuous business process change is often seen as a great virtue, sometimes under the buzzname business process reengineering (BPR).
- If you want to change your processes more incrementally, you likely need one or both of two things:
- App software with more features than you initially need. That may be easy to get, but it isn’t cheap.
- A nimble IT department. That one is neither cheap nor easy.
6. My biggest reason for writing about brittleness and improvement is to approach some topics around analytics and AI. As previously noted:
- Artificial intelligence is facing public skepticism both for being too accurate (!) and not accurate enough.
- Analytics in general is often surprisingly inaccurate.
Please stay tuned.
Related link(s)
- Most of what I wrote in my December, 2015 series about artificial intelligence still holds true.
Comments
2 Responses to “Brittleness and incremental improvement”
Leave a Reply
[…] my initial post on brittleness I suggested that a typical process […]
The concept of brittleness versus incremental improvement is something that applies to almost every technology field. Systems that depend on perfect conditions often look impressive at first, but they can struggle when real-world complexity appears. Incremental improvements may seem less exciting, yet they tend to be more sustainable because they allow teams to learn from actual usage, reduce risk, and adapt over time. I especially liked the emphasis on continuous refinement rather than chasing a single breakthrough solution, since long-term progress is often the result of many small improvements working together.
That same principle shows up in simulation games where success rarely comes from one big decision. For example, the how to earn money faster in BUSSID guide focuses on optimizing many small aspects of gameplay to improve overall results. Likewise, the bus simulator ultimate bus upgrades guide explains how gradual upgrades and strategic investments create better long-term performance than trying to maximize everything at once.