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
One Response to “Brittleness and incremental improvement”
Leave a Reply
[…] my initial post on brittleness I suggested that a typical process […]