June 20, 2018

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:

There are many categories of IT strengthening. Two of the broadest are:

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: 

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.

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..

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.

6. My biggest reason for writing about brittleness and improvement is to approach some topics around analytics and AI. As previously noted:

Please stay tuned.

Related link(s)

Comments

One Response to “Brittleness and incremental improvement”

  1. Brittleness, Murphy's Law, and single-impetus failures | DBMS 2 : DataBase Management System Services on June 20th, 2018 5:15 am

    […] my initial post on brittleness I suggested that a typical process […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.