26 February 2004

by Michael Mah, Senior Consultant, Cutter Consortium

Copernicus, Galileo, Brahe, Kepler, and Newton. It took these five scientists from five countries a span of more than 150 years to break the commonly held worldview that claimed the sun and all the celestial bodies revolved in circular orbits around the earth at the center. This geocentric (earth-centered) model was formulated by the Greek philosopher Ptolemy around A.D. 140.

The Polish astronomer Copernicus was the first to challenge this idea in the early 16th century, about 1,500 years later. However, being a clergyman, Copernicus knew what was in store for him were he to challenge the church’s view of reality, so for 30 years he kept quiet. Just before he died, he published a small book, On the Revolutions of the Celestial Spheres, which arrived in his hands on the day of his death. His fears of repercussions turned out to be valid — the Vatican placed his work on the papal index of banned books, where it remained for 70 years.

Galileo didn’t fare very well either. With his invention of the telescope, he was able to see into the heavens and confirm that the earth was not at the center of the universe. He published Dialogue, in which he defended Copernicus. At his subsequent trial, Galileo was forced to “abjure, curse, and detest” this view, and was placed under house arrest for the rest of his life. Years later, the combined research of the Danish astronomer Tyco Brahe and mathematicians Johannes Kepler and Sir Isaac Newton sealed the deal. The paradigm shift was complete with their scientific proofs of the heliocentric (sun-centered) model. However, it took until 1992 for the Vatican to formally apologize for its treatment of Galileo.

I sometimes believe that it might take similar efforts to change the view that software is the manufacture of code, and to advance the notion that making software (and information technology) is really about design.

Perhaps our modern-day Copernicuses and Galileos are folks like the DeMarcos, Listers, Putnams, Yourdons, Orrs, et al. Fortunately, the Vatican isn’t steadfast in its belief of software as manufacturing or construction, else they might become outcasts too. But there might as well be a church of IT, because it seems that at the root of the struggle about building better and more reliable systems today is the notion that software is constructed.

Peter Drucker was the first to coin the term “knowledge work” — something we can use to describe the activities of the Information Age, where much of our efforts are about design, as opposed to the Industrial Age, where much of our efforts were about manufacturing. I think subconsciously, many of us still view work using Industrial Age paradigms, which is why we look at “building software cheaper, with better quality” as a prevailing principle, as in manufacturing. It seems to me that viewing software as a “product” is also behind the common wish to build more software, faster, like an assembly line. Remember the term “software factory”? It’s also this worldview that looks at project overruns as failures and aims to lower software build costs by outsourcing to cheaper overseas labor as the answer.

What this worldview can’t handle are situations where software requirements change or grow, which is what happens all the time in design. It’s funny how knowledge work behaves that way. According to Cutter’s studies on software estimation, requirements change and scope creep are the root of the problem — 74% of the time — when projects miss their dates or overrun their budgets (more manufacturing thinking here — can you see it?). It’s also the root of the problem when, during a recent Cutter Summit conference, Kent Beck and the ideas of Extreme Programming were criticized as being “allright for pond bridges, but not for anything bigger than that” (more metaphors about building big stuff).

I think it’s also the core problem when bugs soar through the roof when companies ramp up to meet an Internet-speed deadline. One of the nasty uglies about design work is that it doesn’t like to be compressed. You see, software design is about team communication, so when teams get larger, communication paths grow geometrically with the square of the number of people on the team. Amazingly (to many, but not to all), software defects rise nearly in step at this geometric rate. (Please don’t build medical device software or air-traffic control systems this way!)

In his book Slack, DeMarco made a great point about software quality: that it’s inversely proportional to quantity. To build better-quality stuff, it’s simple — build less of it! Problem is, building more stuff faster is the mindset of manufacturing thinking, not design. So what we see in almost every organization I’ve ever consulted to is a lack of attention to managing software size (think scope) within a deadline. Most of the time, we do manage the scope — late, at the end of the project in a desperately hasty retreat, when the deadline looms like a freight train. We have to cut back to delivering only “the core,” because we overpromised how much we can build with the team that we have. In this stressed-out environment, there’s little time to spend on coming up with elegant designs. And to me, design is what can differentiate a really amazing piece of software from another also-ran.

So, what would it look like if we recognized that software and IT is more about design and less like manufacturing?

We’d rethink how we look at “productivity” — and what we mean when we say we want to measure it or improve it. We’d toss out metrics like cost per function point, function points per work-month, or cost per thousand lines of code. We’d reexamine our thinking when we outsource to the lowest-cost producer. We’d realize the implications of the 200/20/6x rule, which says that if you double staff (200% — domestic or even less expensive offshore folks), you might get a 20% schedule reduction (if you’re lucky), but you might also find defects to rise nearly six-fold. Are you medical systems folks listening out there?

Lastly, we’d rethink project management. Most of what we see in traditional project management (MS-Project, et al.) comes from manufacturing paradigms. When we overpromise the amount of functionality within a compressed deadline, the resultant impact often overwhelms the best of project managers, like bacteria overwhelming an immune system. Progressive practices like risk management can hold an answer to the problem, and allow for enough breathing room for the software architects to produce really elegant designs, not only for robust operation, but for form and function.

Fortunately, most folks who advance these ideas haven’t been excommunicated. But don’t worry — it only took one and a half centuries for us to realize that the sun doesn’t revolve around the earth. Now that we’re in the Internet era, realizing that software is about knowledge work, and is more design than manufacturing, should take far less time.

— Michael Mah, Senior Consultant, Cutter Consortium

© 2004 Cutter Consortium. All rights reserved.