Learning to Love Bug-Ridden, Unpredictable IT

Nick Jones proposes a provocative (what he calls "maverick") session to talk about future things with lower probability (of happening) but potentially leading to a massive disruption. This kind of session is also unusual in that these are mostly Nick's own ideas, not necessarily endorsed by Gartner.

Software engineering and project management is just a waste of money, because the software quality remains bad. And Nick thinks that the quality will only worsen, even if putting more money on project management and other engineering processes (think CMMI here).

Software quality is equal to availability + precision. Over time, the high availability and precision types of applications will not be the majority nor the most important.

Software development is not engineering, it is a knowledge acquisition process (until you deliver what the user wants). Human beings do not fit the lifecycle model. Specifications are a snapshot at a time but the delivery will happen later…

An IT sytem is a collection of technology and people. In real life, a development team does not know its goals and does not communicate. They risk no penalties for doing things wrong. With better tools, people build bigger software, not better software.

Systems can be big or robust but not both. Success is pure luck! There is no evidence that this will change in the future.

But does software quality matter? Software is useful whatever its defects and users are tolerant to errors. Digital natives are used to bad quality (perpetual betas). Users concentrate on the speed of fixing problems (agility is more important).

The future: more processing power (multicore), multi-threading and parallelism (leading to a development and testing nightmare: Heisenberg principle).

Then there is Web 2.0, mashups, SOA and clouds: nobody controls the architecture and even knows where things are. These are parallelized as well. This makes things even worse.

Consumerization is the enemy of software quality because the number of independent participants, devices, user interfaces, networks, technologies increases.

However, sometimes you don't need precise answers: think context, adaptative systems (neural networks), social networks…: these are fuzzy systems.

Everyone wants agility but it "corodes" strategy, there is a looming skills crisis, some new development tools are dangerous weapons in more and more amateur hands… Take a look at these risks and distribute the list in your organization.

Surviving means to get rid of the fantasy of software engineering but to learn to live with bug-ridden software.

Recommendations (summarizable as a shift from a focus on functional bits to a focus on operational issues):

• Design paranoid systems
• Testing moves to runtime (monitoring oriented programming)
• Avoid monocultures (redundancy, clean room implementations of key algorithms).

Acceptability-Oriented Programming is emerging from the idea that the goal of perfection is counter-productive. Failure-oblivious computing, recovery-oriented computing, "resilient actors" (all being academic topics at the moment) are some other approaches to the fact of imperfection.

More practical solutions include autonomy (limiting risky dependencies and increase resilience, maybe as a failover solution), allowing human intervention, software updatability.

From a social point of view, politicians are also a risk, because they don' t understand IT. Users should be educated (think of something on the line of "there is a 30% risk of rain today" or MS Outlook telling you that "there is an 80% chance that your mail reaches its recipient"). But the politicians would probably interfere.

There is an opportunity with massively parallel low cost processing + unpredictable computing: genetic algorithms, hybrid human / cloud solutions (e.g. mTurk or HumanGrid). Find where these things could be used.