Imagine waking up tomorrow and learning the construction industry has made the breakthrough of the century. Millions of cheap, incredibly fast robots can now fabricate materials out of thin air, have a near-zero power cost, and can repair themselves. And it gets better: given an unambiguous blueprint for a construction project, the robots can build it without human intervention, all at negligible cost.
One can imagine the impact to the construction industry, but what would happen upstream? How would the behavior of architects and designers change if construction costs are negligible? Today, physical and computer models are built and rigorously tested before investing in construction. Would we bother if the construction was essentially free? If a design collapses, no big deal...just find out what went wrong and have our magical robots build another one. More implications follow. With models obsolete, unfinished designs evolve by repeatedly building and improving upon an approximation of the end goal. A casual observer may have trouble distinguishing an unfinished design from a finished product.
Our ability to predict time lines will fade away as well. Construction costs are more easily calculated than design costs -- we know the approximate cost to install a girder, and how many girders we need. As predictable tasks shrink toward zero, the less predictable design time grows to dominate the project. Results are produced more quickly than before, but reliable time lines slip away.
Of course, the pressures of a competitive economy still apply. With construction costs eliminated, a company that can quickly complete a design gains a market edge. Pressure on getting design done fast becomes the central push of engineering firms. Inevitably, someone not deeply familiar with the design will see an unvalidated version, see the market advantage of releasing early, and say "This looks good enough."
Some life-or-death projects will be more diligent, but in many cases consumers learn to suffer through the incomplete design. Companies can always send out our magic robots to "patch" the broken buildings and vehicles they sell. All of this points to an amazing, counter-intuitive conclusion: our sole premise was a dramatic reduction in construction costs, and the result is quality got worse.
The Design Crisis
It shouldn't surprise us the above story has played out in software. If we accept that code is design -- a creative process rather than a mechanical one -- the software crisis is explained. Now we have a design crisis: the demand for quality, validated designs far exceeds our capacity to create them. The pressure to use incomplete design is strong.
Fortunately, this model also gives us some clues on how we can get better. Physical simulations equate to automated testing; software design isn't complete until it is validated with a brutal battery of such tests. To make such tests more effective we are finding ways to rein in the huge state space of large systems. Improved languages and design practices give us hope. Most importantly, there is one inescapable fact. Great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different.
6 comments:
Ryan, very insightful. I can't argue with your viewpoints. I suspect though that there's no real way to solve the problem other than by educating the corporate folks... they're always looking to break or bend the three-fold rule - "fast, cheap, good - pick 2". Until they acknowledge the reality of that, there's always going to be problems.
Ryan, very cool blog. I think you are the Ryan Brush with whom I went to college.
Anyhow, I think there is something to be said about a design process that allows you to bring partial design to a customer to validate that you are doing the right thing for the consumer. Sometimes engineers with the best of intentions design something perfectly to match a certain goal and we later find out that goal isn't profitable or even what the customer wants.
Anyhow, keep up the interesting blog.
Oh, I've got one, too:
http://conceptuali.blogspot.com/
Very interesting idea.
Oh, and in the last paragraph you mean "rein in" (pull on the reins), not "reign in" (rule over).
Laurie - thanks, fixed the typo.
Amy - it's been a long time! I agree with your comments regarding on sharing partial designs with customers, for the reasons you mention. I hate stretching analogies, but we might compare this to a model of a building, or 3d simulation shown to a client. Those of us in software just need to make sure our clients understand when it's only a model.
Very insightful, Ryan. I also think much as you do, and find analogies very helpful in understanding why things are as they are.
I think there are some understandable reasons why this crisis has occurred. Any moderately advanced software is much like a machine (a Rube Goldberg machine usually!) However, like your building analogy, it is a machine whose parts are made of almost invisible, almost free parts.) BTW, I design and implement large scale automated testing systems, and I agree with you on that point. When design and construction are so low cost, design verification (testing) is essential. You must functionally demonstrate the system, since it is basically a black box to most people involved. Even to the programmers... for whom their own code may be a white box surrounded by various grey and black sections of code. It also is of a complexity level that it exhibits emergent behavior for which the state of the industry today lacks any means of simulating, and thus functional testing is the only practical approach to characterize or quality the software.
The last comment I will make is that most of the failings of software design are in the area of requirements definition. I see the recent social software trends as being a key development. I hope to develop a social software requirements definition technology (OpenSource) and for that reason I purchased the domain name "OpenRequirements.org". I am seeking collaborators in this endeavor.
"You get what you pay for" is my motto. There are a number of reasons as to the cause of the crisis you've outlined.
A flood of newbies into any field tends to depress the average quality of work in that field. Until the newbies either get good, or leave when they realize it's not for them. But anything which can be done over the 'net (like software programming) is instantly appliable to the entire world.
Outsourcing is cheaper, yes, but the quality is always inconsistent. If your sole motivation is 'cheap', 'good' is placed on the back burner.
The real challenge is in identifying people who know what they're doing. Unfortunately, only people in a given field who know what they're doing are qualified to make that judgement. Therein lies the paradox...
Post a Comment