Silver Fever
Note: I wrote the first version of this paper in 1995... It’s still relevant. Sigh.
In 1975 Fred Brooks pointed out the futility of searching for a silver bullet, some technology that would improve software quality and productivity by an order of magnitude or more. Not surprisingly, the compelling nature of the silver bullet concept has kept computer professionals and customers searching for these elusive nuggets for years.
Like the 1800’s there are hordes of people afflicted with a modern-day version of silver fever. Like the 1800’s we have people trying to get rich quick, trying to avoid doing the hard work of designing and building quality solutions by finding some kind of silver bullet buried in the technical landscape.
To supply the various miners we have computing vendors getting rich selling tools and supplies, knowing the odds of finding silver are slim at best, while claiming their tools are the secret to finding it. See if you recognize any of these recently published claims:
“…state-of-the-art innovations in productivity…”
“…lets you create [applications] in no time at all.”
“Even if you’ve never worked in … before.”
“The Web is the Holy Grail of Computing!”
Between technology miners, vendors, and industry press we’re bombarded with messages telling us our choice of technology determines our success.
In reality, the opposite is true.
Technology affects pace, not outcome.
Failure is guaranteed only when we begin to focus on technology for technology’s sake or look solely to technology to solve our problems.
The moment we stop depending on quality people, principles, and practices and start depending on technology we’ve caught silver fever. We’ve replaced common sense with a silver bullet. Failure is sure to follow.
Avoiding silver fever is simple if we remember a simple axiom: Technology affects pace, not outcome.
Technology can dramatically increase the speed with which we can develop new systems.
It affects our pace.
Technology can’t ensure that what we build, fast or otherwise, will actually solve our business problems.
It doesn’t affect our outcome.
Technology provides us with tools like editors and screen painters and materials like languages, databases, machines and networks. What we do with these tools and materials is up to us. If we lose perspective, if we focus on tools and materials rather than focusing on solving business problems; we’ve caught one of the many varieties of silver fever.
Tool Fever
Most of us would agree with the statement “Good tools improve productivity.” Vendors use similar statements in their brochures precisely because they’re hard to argue with. What are dangerous are the assumptions we make based on these simple “truths”.
It’s easy to assume a user can become as productive as the brochure or demo would lead us to believe…and that it will happen in a timeframe relevant to our project. It’s easy to assume the tool will produce quality results regardless of the quality and experience of the user wielding it. It’s easy to assume the material a tool is designed to manipulate is the right material for our project.
None of these assumptions is valid.
The Software Chainsaw Massacre
Scattered around the world are a number of individuals who carve beautiful sculptures from full-size logs using nothing but a chainsaw. In the hands of these artists a chainsaw is an unparalleled power tool capable of creating art in record time. No hammer-and-chisel-toting sculptor is going to keep up with these guys.
In the world of chisels and chainsaws we have enough sense to realize we’re seeing the result of a good match between a particular craftsman and a particular tool. A match resulting from years of practice. We’d never assume a) that we should outfit all sculptors with chainsaws because of “increased productivity” b) that we should train new sculptors by handing them a chainsaw or c) that the chainsaw has anything to do with the quality of the art. We immediately recognize the experience, talent, and craftsmanship of the artist.
A chainsaw may be a fast way to cut things, but it doesn’t aim itself. It’ll cut into a log or a leg with equal ease. Whether we end up with art or a quick trip to the ER depends on the skill of the user. Using a chainsaw vs. chisel just lets us find out which it’ll be in record time. Software tools are no different.
Garbage In -> Garbage Out
With all the hype it’s easy to forget a tool’s output can never be of higher quality than the quality of the material it’s manipulating and the skill of the craftsman using it. Output quality will never exceed input quality.
We’ve heard this time and again in an easy-to-remember form but we keep forgetting it:
Garbage in — — — — — — — — — → Garbage out.
Using a better tool doesn’t imply Garbage in -> Quality out. A better tool just outputs garbage faster. While we might be able to perform a few more iterations because of the tools we still get nothing more than:
Garbage in -> Garbage out -> Garbage in -> Garbage out -> …
Tools are facilitators, not creators.
While today’s software tools can generate application shells or data entry forms, such tools have no control over whether they are the right data entry forms. To ensure we’re building the right thing requires analysis of the business problem and thoughtful design by a qualified architect.
Interestingly, architects don’t focus on tools. They realize that a successful design combines the right materials, in the right proportions, in the right locations. A qualified architect is familiar with a variety of materials and understands their strengths and weaknesses. The architect uses this knowledge to ensure each element of the system is built using a material that’s sufficient for the loads that will be encountered.
It seems clear that tools can only be chosen after the architect has defined the materials needed to complete a system. To return to our sculpting example it wouldn’t make much sense to be out comparing chainsaws, arguing over prices and specifications like 12" log-cuts-per-minute, if we’re going to sculpt in concrete.
The best way to avoid tool fever is to focus on the materials needed for success and leave the decision of which tools to use for manipulation of that material to the craftsmen doing the work. Avoiding tool fever doesn’t ensure success however. Fevers related to materials are just as common…and just as dangerous.
Material Fever
Like tool vendors, material proponents make claims that are hard to argue with. Technical specifications and benchmarks are the favorite weapons of material vendors. From CPU speed to transactions-per-second, the various vendors publish everything possible to convince you their product is critical to your project.
“But”, you may ask, “aren’t faster machines, faster networks, better languages, and more powerful databases essential to success?” It depends. Since virtually all development is done within the constraints of a budget each decision must be weighed carefully. Failure to meet budget is still failure. The fact that the system runs fast isn’t of much comfort if you’re broke…or too late. Likewise, all the statistics in the world won’t help you run faster if your system doesn’t rely on the features of the product being benchmarked.
A Performance Quiz
A keyboard buffer is an area of computer memory used to store what you type. If the space is too small its possible to type more characters than the machine can process resulting in a buffer overflow and lost input. The question is how fast does the machine need to handle buffered characters to prevent lost input?
If you used research that shows a good typist can type 120 words per minute (about 600 characters) and answered “600 characters per minute plus 10% for safety” you’re healthy. You may occasionally find a typist who breaks the 120 word-per-minute barrier but you’ve made a sound engineering decision based on research and statistical analysis. If you skipped the research you’ve caught the fever.
Many projects assume the answer to our quiz is “as fast as possible” without knowing what’s required. With the goal of buying the “best” technology these projects make what they like to call an “informed decision” based on technical specs and benchmarks. Sadly the “informed” element of their decision has nothing to do with being informed regarding project requirements and the materials that are best suited to meeting them.
These informed projects often find out, only after the system is deployed of course, that the system is too slow to be useful. The project fails spectacularly having spent valuable time and money on something that doesn’t solve the business problem. The fastest and best weren’t sufficient to meet project needs.
On the other hand, the project may find out, again only after deployment, that 90% of system resources are unused implying they paid for more performance than necessary. The project may or may not fail but the budget isn’t as healthy as it could be. The fastest and best were far more than the project required.
Given that insufficient performance leads to almost certain failure while buying too much simply leads to cost overruns, most projects skimp on — or completely ignore — detailed analysis. Better to have a cost overrun than a certain failure. What these projects don’t realize is they are playing a very deadly game.
Software Roulette
Using the “best or latest” approach is like playing Russian Roulette with your project. Just imagine that for every technology that coincidentally exceeds your project requirements you get an empty chamber in the gun. Technologies that don’t exceed your requirements put a bullet in the chamber. Without solid analysis and design behind each choice of technology you have no way of knowing how many bullets there are.
This game is played with predictable results. Some projects succeed. Most die. Results for different projects using identical technologies are random and unpredictable because technologies that are adequate for one project aren’t sufficient for another. One project’s empty cylinder is another project’s loaded gun.
If the random and unpredictable nature of this game sounds frighteningly familiar it should. Having found the latest, fastest, most powerful technologies available many projects simply load their arsenals and pull the trigger. The result is usually death by silver bullet.
The best way to avoid material fever is to hire a qualified architect — before you do anything else.
A qualified architect has experience with a variety of materials and construction techniques. This includes experience with different hardware (PC’s, UNIX Workstations, Mainframes, etc.), network configurations (Ethernet, Token-Ring, etc.), database technologies (Hierarchical, Network, Relational, Object-Oriented, Temporal, etc.), programming languages (Basic, C/C++, Java, Smalltalk, Lisp, Fortran, Perl, etc.), interface models (Text-based, Windowing, Tiled, etc.), etc. Without a broad base of experience across all areas of system construction an architect is too limited in their knowledge of what’s possible to design effectively.
Unfortunately a lot of projects fail because, while they thought they had an architect, what they really had was an evangelist.
Evangelical Fever
According to Webster’s an evangelist is someone who “preaches the gospel”.
For technology this often takes the form of preaching the gospel of the Web, the gospel of Objects, the gospel of Functions, the gospel of Java, the gospel of Microsoft etc. Caught up in the hype-generated evangelical fever surrounding a technology, evangelists stop focusing on results and focus on the technology. This has serious consequences for your project.
Like traditional construction, in which the choice of wood, stone, concrete, and other materials determines the strengths — and weaknesses — of the final product, successful software design requires care regarding the materials used. Evangelism short-circuits design by focusing too heavily on a particular technology.
The typical result of an evangelist acting as an architect is a structure designed using a single material. This is analogous to building an entire structure out of glass block. Doors, windows, walls, floors, and ceilings, everything is glass block. Why? Just ask the evangelist. “Glass block is great. Glass block has wonderful performance characteristics. Glass block is cheap. Anyone can learn to use glass block.” Blah, Blah, Blah.
If it sounds strange in traditional construction, why do we accept it in software? “C++ is great. C++ has wonderful performance characteristics. C++ is cheap. Anyone can learn to use C++.” What starts out as a seemingly harmless infatuation with a technology’s strengths rapidly becomes a project’s worst nightmare.
Architects vs. Evangelists
Unlike evangelists, architects are generalists. To be effective an architect must be familiar with a wide variety of materials. The architect must have a clear, unbiased view of the strengths and weaknesses of each material. This knowledge and relative lack of bias allows the architect to make appropriate choices about how the various design criteria can be met using available technologies.
Unlike designs by evangelists, designs by architects typically combine a variety of materials. The use of different materials makes sense. Different languages have different characteristics just as different elements of a system have different requirements. The user interface of an application is the area that undergoes the most change over time. It makes sense, therefore, to implement the interface using a flexible technology.
With a little imagination it’s possible to draw analogies between programming languages and structural materials. For example, one could imagine C++ as structural steel. It’s strong. It can handle heavy loads. And it isn’t easy to change once it has been put in place. Java is like wood. A bit less strength, a bit less load handling, but easier to manipulate. If C++ is steel and Java is wood, HTML is like putty, light, easy to manipulate, and easy to alter. The choice of which to use depends on project requirements.
Craftsmen vs. Evangelists
Craftsmen, like evangelists, are specialists. The difference is the maturity they display regarding their technology and their talents. While craftsmen and evangelists are only too happy to discuss the strengths of their chosen specialty, only the craftsman is likely to discuss the weaknesses with equal candor.
For a true craftsman it makes sense to specialize in a particular technology. Long-term experience with a single tool or material is what it takes to develop the skill needed to produce quality results. Constant change implies constant re-training and constant mistakes due to inexperience. Their desire to build with quality leads craftsmen to focus. Evangelists, on the other hand, often float from one technology to another, praising the merits of the latest technology without understanding the strengths of existing alternatives.
Between Two Worlds
Evangelists are essentially caught between two worlds. Their tendency to focus on the technology-de-jour implies they are specialists making them unsuitable as architects — they may not have the broad focus needed for unbiased design. On the other hand, that tendency to follow fashion makes them unsuitable as craftsmen — they don’t stay with anything long enough to become truly skilled.
Maturity is the only cure for evangelical fever. Since no technology is perfect for every application it’s simply a matter of time before experience proves to the evangelist that their technology-de-jour is good for some things and not so good for others. What do you do with the evangelist in the meantime? Depends on where they are relative to you in the org chart :-).
Architects and Craftsmen — or Rescue Workers?
In the popular movie “Apollo 13” there’s a scene where a bunch of guys are standing around a table. A manager walks in carrying a box full of miscellaneous parts. As he approaches the table he begins speaking dramatically. “Gentlemen”, he begins, “we have four hours to make this (a square peg) fit into this (a round hole) using nothing but this (the contents of the box).” At which point he unceremoniously dumps the contents of the box on the desk.
Let’s make a few minor changes. This time it’s the first day of the new project. Your manager starts speaking. “Gentlemen”, he begins, “you have four months to make this (a purportedly mission critical business application) run on that (whatever hardware/operating system combination is currently under- utilized because some prior project over-purchased) using nothing but this (whichever technologies-de-jour were recently purchased coupled with whatever technologies are lying around from previous failures). At which point he dumps the whole thing in your lap.
Sound familiar? Far too many software projects begin this way. And almost all software projects end up the same way too…late, over budget, and incapable of solving the stated business problem.
Starting projects in this fashion essentially turns qualified software engineers into rescue workers. It’s no wonder that achieving success in software development requires the same unique combination of talented engineers, inspiration, desperation, and luck as the Apollo 13 mission.
Curing the Fever
As a customer, avoiding a rescue mission is simple. Step one: define your business problem and the budget you have available to solve it. Step two: hire an architect to define the solution. If you have the talent and experience to define the solution correctly then simply recognize that you are the architect. If you’re not comfortable with the responsibility that role implies go back to step one.
If you’re acting in a customer role you are responsible for defining the business problem and the budget available to solve it. Period. Rather than succumbing to silver fever, customers have to focus on defining what they will accept for deliverables. Focusing on what instead of how is the top priority for customers.
If the customer’s focus is on what needs to be done, the architect’s focus is on how to accomplish it. The architect translates a customer’s definition of what is needed into blueprints describing how it can be built. Doing this requires the ability to ask effective questions. Usually when a project fails because requirements “changed unexpectedly” it’s because the architect didn’t do their job. Requirements don’t change as fast as we like to think…they just get discovered during development instead of design. During construction, the architect serves as a liaison between the customer and the various personnel involved in construction.
A successful architect is a translator, not a dictator. An architect should never put their design ahead of the customer’s business needs. If they do, they’ve reverted to acting as an evangelist…of their design.
Craftsmen can only be chosen after the customer and architect reach agreement on a proposed solution. Prior to that agreement the materials of construction are still open. Only after the specific materials, their functions, and their interfaces to each other, have been defined can proper hiring of craftsmen be done.
The craftsman is responsible for manipulating the architect-specified materials into the desired end result. To accomplish this goal the craftsman chooses tools appropriate to the material and the task. Contrary to popular belief, this leaves craftsmen a lot of room for creativity. Like traditional blueprints showing the rough location of lights but not the wiring, good software blueprints should define only the interfaces and general layout of the structure. The craftsman fills in the details.
Designing and developing in this fashion eliminates silver fever and replaces it with common sense. And that, after all, is the best weapon we have for controlling complexity and creating successful systems.
ss
