On supporting science journalism
If you're enjoying this article, consider supporting our award-winning journalism by subscribing. By purchasing a subscription you are helping to ensure the future of impactful stories about the discoveries and ideas shaping our world today.
Most people surf the Web, gab on their cell phones, and stop for cash at an automated teller machine (ATM) with nary a thought of how they're able to accomplish these feats. They simply take for granted that these devices will work at the touch of a button.
Reminder: these devices would be useless were it not for the software that instructs computers to communicate with the Web, cell phones to find signals, and ATMs to confirm that customers are cleared to receive and deposit funds.
In other words, software is the heart and soul of today's array of gadgets—and, the way it is written is crucial to their operation. The problem is, however, there is no one manual dictating how it should be written. In essence, programmers now simply string together commands to make devices do what consumers expect them to do. There are no rules for software developers to follow, such as those that guide most engineering disciplines, and there is no historical frame of reference code writers can study to determine which approaches work and which do not.
IBM fellow and self-proclaimed "software archaeologist" Grady Booch explains why this needs to change—and what it will take to bring software writing into the 21st century.
You say there's a "dirty little secret" when it comes to writing software. Care to share that with us?
In other disciplines, engineering in particular, there exist treatises on architecture. This is not the current case in software, which has evolved organically over only the past few decades. All software-intensive systems have an architecture, but most of the time it's accidental, not intentional. This has led to the condition of most software programming knowledge being tribal and existing more in the heads of its programmers than in some reference manual or publicly available resource.
By not having a codified approach to writing software, we're playing with fire. How so?
Our society now runs on software. As a general rule of thumb, worldwide, software developers produce around 33 billion lines of new or modified code per year, and it quickly becomes outdated as new demands are placed on software. If I don't have a sense of the architecture, and I keep piling on code, it becomes a fetid mess. The danger of this stagnation to a large business is that if a smaller and nimbler competitor comes along with a better way of doing things, the large business has trouble adapting and can easily lose its leadership position in a given market. There becomes a fundamental economic reason for software architecture then. This is particularly difficult for growing businesses that are completely based on software, companies like eBay or Google, which don't actually manufacture anything tangible and yet who rely on software as central to their business.
How big is the problem of haphazard software writing?
Today's cumulative mass of software is large. Given the serious capital investment that has been made in the software that already exists today, it can't easily be changed. Microsoft at one point decided that Word [word processing software] was getting creaky and tried to rewrite it from the ground up [as part of the 1991 Pyramid program]. The problem with that approach is that they never quite got their new Word to match the original software. They had to go back and work with the code they already had.
What impact does the Web have on software architecture?
The Web doesn't change the basic idea of a software architecture, but rather represents a particular software architecture genre, against which systems can be built. That being said, there do exist some design "flaws" in the Web; these "flaws" are not so much evil as they simply could not have been known a priori. There is poor separation between the Web's presentation and its semantic layers, which need to be allowed to change independently. Another challenge is the Web's underlying TCP/IP [transmission control protocol/Internet protocol] protocol, which was never designed to support the streaming video so popular on sites like YouTube. When TCP/IP receives a request and then provides a response, it breaks up the flow of information, which is a problem when you're trying to play streaming video.
What can be done to improve software?
There needs to be a consistent way of writing software that runs on different systems and in different situations that considers a number of different factors: Is the software running on a single machine with multiple processors or is it running on a cluster of single-processor machines? Will all of the software source code go into a single file on the computer, or will it be broken down and executed as multiple scripts? How will the software define and use the different data it encounters? These are questions that must be answered before the software is written in the first place. In civil engineering, if you ask someone to build a Victorian house, there is an inherent understanding of what that looks like. If you ask different programmers to design software for a high-throughput system [such as one that processes financial transactions], there's no general agreement of how that software should be built.
How can tomorrow's computer scientists be better prepared to adopt a more universal approach to writing software?
Because business has pushed advances in software out of necessity for so many years, academia has had to play catch up, rather than teaching and establishing a software architecture for subsequent generations to follow. One approach is to teach young programmers through a tutorial such as "Alice," which is a 3-D software writing program designed to make it easy to create an animation for telling a story, playing an interactive game or making a video to share on the Web. Alice was created by a team of programmers led by Randy Pausch [a Carnegie Mellon University professor of computer science, human–computer interaction and design] and is a freely available teaching tool designed to be a student's first exposure to fundamental programming concepts.
You're known as a software archaeologist. Does that mean you carry a bullwhip and chase down artifacts like an information technology Indiana Jones?
I approached the board of trustees of the Computer History Museum [in Mountain View, Calif.] and told them they should also have a museum of software. It would be a sad thing…[for]…future generations if we didn't have access to the original source code for, say, Word. I can't find the original source code for [IBM's mainframe operating system]; not even IBM has it. It's hard to get access to some of this software because it's proprietary and businesses don't want their competitors to see it. We're conducting an archaeological dig for software so that future generations can study it and improve upon it.