The Business Shell in an Age of Hype

In the book "Facts and Fallacies of Software Engineering", long-time software design researcher Robert L. Glass (Home Page) discusses many myths of running a computer division in a modern company. The reality of computing is that most new techniques, bureaucratic processes, advanced tools and management methods simply don't live up to their promises. Glass describes it in this way:

There's been any number of so-called "magic bullets": smarter editors, extreme programming, agile programming, CASE tools, object-oriented programming, Service Oriented Architecture, etc. Some of these had no improvement in productivity, others small improvements. But none of these were the break-though techniques that would improve productivity by a factor of 10 or more.

Even the optimistic value of 35%, according to Mr. Glass, was not achieved through some new technique. That's the improvement gained by code reuse--breaking your program up into reusable subroutines by defining plain old functions or classes.

A little common sense would back that up. Consider programming languages. Java (Java Home Page) was designed as an improved version of C++. Problems are expressed in the same way as C++. The fundamental syntax is the same, with the same well-known flaws. Java and C++ (and C# for that matter) are tools of the same category. So one should not expect Java to make exponential productivity improvements over C++. The same is true of PHP versus Perl as PHP was based on Perl.

So where does that leave my claims about my Business Shell (Bush, Bush Home Page)) as a better way to develop software? Is it hype like extreme programming?

Unlike Java, Bush was not designed to remove annoying quirks in a programming language. It was not intended to be an enhanced Bourne Shell or to solve the problems of Ada 95 (Wikipedia), the language it is based on. Bush was designed to solve problems in software management problems in businesses environments.

I was perplexed with the problem that I refer to as code aging. I once worked in a company that had created a simple shell script to print a Windows spreadsheet on a UNIX printer. This shell script grew and grew until it became a web-based report generator with thousands of lines of programming.

But the programming was all written in shell scripts. Shell scripts use a different programming paradigm than other programming languages. Shell variables do not function like variables in other languages. Shell if statements do not function like if statements in other languages. To convert a shell script into a standard programming language, the solution would have to be constructed in a different way. That means a total rewrite of the software. What was needed was a shell that used the same paradigm as another, more popular programming language.

There are plenty of shells based on My Favourite Language. What I needed was a language to solve the code aging problem: something designed to handle small programming that could evolve and grow to millions of lines of code maintained by dozens of developers without falling apart under the language's limitations. The only top-20 programming language to meet that criteria was Ada. Ada is a language designed from the ground up for large teams, large-scale development and high reliability. Projects scale up over time and Ada was a language designed to be scalable. It was the only suitable language on which to base the Business Shell (Is Ada Good for My Business?, Aonix White Paper).

This problem of software failing to be maintained as it grows or changes is not new. Author Jaron Lanier (Wikipedia) expressed the same concerns in the "Wired 24/7" episode of TV Ontario's current affairs program, "The Agenda" (The Agenda Home Page). Lanier pointed out that hardware follows the predictable pattern of Moore's Law while software does not.

I would also agree with Mr. Glass that the software industry lacks a lot of serious, objective evaluations of claims. The problem is not limited to the software industry. In Wired magazine (Wired Home Page), researcher David Eddy discusses the problem of getting good evidence in medical trials. In the late 1980's, Eddy recommended that insurance companies not fund a new and risky cancer treatment on the grounds that it had no solid proof of results. "The dispute ignited the national media. 'The country was in a furor," Eddy says. 'We held the line and stopped a dangerous treatment,' he says. 'The first rule is Thou Shalt Have Evidence.'" ("The Body Synthetic", Wired December 2009). The cancer treatment was later proven to be a failure.

The Stephen F. Zeigler study (Comparing Development Costs of C and Ada, Rational White Paper, also referenced in "Business Shell: Critics say 'I Don't Get It'", Lone Coder), which shows Ada delivers projects with many times less bugs that the leading conventional language, and with 50% less cost, is based on only one project (although that project had nearly two million lines of code and had large teams of skilled developers). It also hasn't be repeated, to the best of my knowledge, with tools developed in the last few years.

True, the Business Shell is only version 1.0 and there's a lot more I would do with it if I had time, funding or an active development community. I think there is a lesson here. The Bush approach has a lot of surface improvements over conventional languages ("Doing it Right with the Business Shell", Lone Coder). However, what makes the Business Shell more than hype is that it is designed to tackle big, enduring projects. It requires a different way of thinking about software. That's what it takes to invent truly revolutionary software technology. Can the Bush approach improve productivity by a full order of magnitude? That's not feasible for any software tool or management technique. Yet there are valid studies that suggest it could greatly improve quality and cut production costs by half over the long term. That's a lot better than CASE tools, Extreme Programming, Agile Programming or even object-oriented programming have deliver. This is because it looks at the big picture.

Software tools and methodologies often focus on short-term issues for product delivery, not the long-term problem of managing software. The software industry needs more people working to solve the big problems and we need more unbiased evidence to qualify how we can put these techniques and tools to best use.

December 23, 2009