Why is the next major paradigm shift in software design about to happen?

Sunday, November 20, 2011 gc 0 Comments

What is the next major paradigm shift?
In my view, the next major paradigm shift in software development will be asynchronous (or async) programming and design. It is our next paradigm shift because it helps alleviate pressures and follows a surprising progression. Only when we change the way that we program, does it change the way we design. When we significantly change the way we design—a major paradigm shift occurs. This change has been brewing for over ten years, but only now is it about to happen.

What is async programming?
Async programming uses asynchronous method calls instead of synchronous calls especially for potentially long-running methods. The idea: you make an asynchronous call and then provide a mechanism to run code when the result returns. Async programming is necessary for responsive browser, mobile, and upcoming Metro style apps that are mono-threaded as well as for intensive multi-threaded server applications. When all components are async, it can be fluid, natural, and resilient.

Why is async design the next major paradigm shift?
The main reason is that it helps satisfy a strong and growing need: to make use of multi-core processors and to make mono-threaded user interfaces highly responsive. In-browser apps allow only one thread.  Async programming makes both possible. New mechanisms for async programming in upcoming C# 5.0 makes it much easier. Asynchrony dramatically affects design.

The shift also follows a surprising progression. Realize that for the past 50+ years, we have had stable high-level programming elements: data, functions, and threads; although combining them was a challenge.

Even though structured programming and design (SP/SD) techniques are still used today, before the mid 90's, it was the conventional or mainstream way to build applications. The problem: structured design treated data, functions, and threads as complete separate abstractions.

Today, object-oriented programming and design (OOP/OOD) techniques are the conventional way to build applications. Object-oriented programming and design combine data and functions into a single mechanism: the class or object.

Async Programming and Design (AP/AD) gives us a simple way to combine all three into a simple unified mechanism. An async object or agent consists mostly of asynchronous method calls. New mechanisms in async programming make it easy to combine data, functions, and threads.

These paradigm shifts (structured, object-oriented, and async) have gradually combined these high-level programming elements. Each paradigm shift has always started with changes to programming, and then to our designs. Only when it moves to design do we realize that a paradigm shift has occurred.

High-level programming elements in relation to paradigm shifts.
If this is truly the progression, then async programming will lead to async design. It might also hold true that async design is a natural evolution in computational thinking. Moreover, it provides an easy way to map to multi and mono-threaded applications and to avoid deadlock, latency issues, and race conditions.

Why is it about to happen?
It is about to happen because great mechanisms for Async Programming are about to become mainstream that will make it much easier. And once async programming becomes mainstream, then so will async design. Our designs are about to significantly change and a major paradigm shift will follow. This has been brewing for over ten years. Just as with structured design and object-oriented design, it took over ten years for it to evolve and become mainstream.

What are the implications?
Today, best of breed architectures consist of a directed-acyclic graph (DAG) of object-oriented components. Fully async objects or agents can help flatten this DAG of components reducing overall dependencies. Realize that most of today’s software architectures are probably not the best of breed.

Looking back, structured design led to some of the least desirable forms of cohesion and coupling. OOP/OOD led to much more desirable defined shapes of software. For me, the revelation at a time of uncertainty for the OOP/OOD paradigm shift was that it naturally led to more desirable forms of cohesion and coupling.

One of the key benefits of Async Design is that it leads to even better shape, and reduces overall dependencies. Flattening the DAG will be the required for ever-increasing architectural complexity. Great software design will, eventually, require software intelligence.

Asynchronous systems are radically different and will require new patterns, architectural viewpoints, mechanisms, and education. Unlike synchronous systems, asynchronous systems will not be halted like an assembly line due to a single point of failure or delay. Asynchronous systems will be even a truer reflection of the way a real company operates—like an organism—not an object-oriented an system.

A new category of software patterns will emerge. These new patterns will help us deal with more autonomy and system intelligence.

We will begin to design fully autonomous objects that consist primarily of async methods that leverage mono and multi-threaded environments.

Where can you go from here?
Change the way you program and it will change the way you design. Check out some of the resources below for more information on async programming for .NET.

You know you are close to crossing this chasm within your company or team when the last objection is performance. Unbelievably, functions were thought too costly for structured programming and dynamic binding was thought too costly for object-oriented programming. Once people overcome the performance objections of asynchronous methods, we will know that the industry is about to shift.

Soon, great designs that are fluid, intelligent, natural, and resilient will be async.

Where ever we go, make the most of it. If you do not enjoy programming and design, then you are probably doing something wrong.

Additional Resources
Async CTP (can be used with .NET 4.0)
Metro async/await 
C# 5.0
C# Specification

You Might Also Like