No Silver Bullet!

I read an excellent essay today, called No Silver Bullet. Joel Spolsky linked to it from his blog about the future of Java. He said that to this day, it is one of the better essays on the limits of software languages.

The essence of No Silver Bullet is that there is a law of diminishing returns when it comes to new software tools and programming languages. At the beginning, the first few tools like compilers, C, and Unix increased productivity tremendously. However, every new technology gave fewer and fewer gains.

Why not? Because these tools are not addressing the actual problem.

Gathering requirements, transforming them into logic, and finally into a working application will always be difficult. There is no silver bullet to fix this. New tools and techniques help, but only so much. Java's memory management made some things easier, as did scripting languages with loose typing, as did the concept of reusable code modules. However, none of these were a panacea that allowed non-technical people to create applications.

No Silver Bullet is nearly 20 years old... considering how quickly the software industry changes, its remarkable how much of his advice is still relevant. Its also a sobering reminder at how skeptical we should all be about any fancy new tool or technique that promises productivity gains...

[ Next: Code Visualization Tools Are Crap ]

Code Visualization Tools Are Crap

In one of my favorite sections he warned us to always be weary of any tool that lets you visualize code. Such tools demo well, because they can create trivial applications quickly. But any real-world application of sufficient complexity is nearly impossible to represent graphically.

Why? No Silver Bullet chimes in with this nugget:

Software is invisible and unvisualizable... The reality of software is not inherently embedded in space. Hence, it has no ready geometric representation...

As soon as we attempt to diagram software structure, we find it to constitute not one, but several general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These graphs are usually not even planar, much less hierarchical.

To put this in English, software kind of exists in its own little universe. Any time you have more than 3 state variables (ie. product, customer, and date), you usually need a 3-dimensional graph to fully diagram the behavior... which is already a bit tricky to display on a 2-dimensional computer screen.

Naturally, if the relationship is simple, you can get by with multiple 2-dimensional diagrams... but in theory we're already in trouble if our application uses as few as 3 variables to describe its behavior.

Now... imagine trying to diagram a software application with ten variables. How about a hundred? How about a thousand? How would you propose to draw a 1000-dimension diagram on a computer screen?!?! The essay chimes in again:

the flowchart... has proved to be useless as a design tool--programmers draw flowcharts after, not before, writing the programs they describe.

True true...

Database tables are the only things I draw out before I start coding. In that case, a table with columns and rows is very easy to visualize. However, flow-control diagrams have never helped one bit. I generally use pseudocode to map out the logic, which works perfectly well. I only create the dreaded flowchart when forced to.

The Best Approach

So what's the ultimate solution? How can we as software developers allow non-technical people to understand our code? I believe the short answer is, we can't... To clarify, I believe it is impossible for a non-technical person to genuinely understand what a computer is doing on the inside.

In fact, some of Turing's computation theories (from the 1930s) imply that its impossible for anybody to genuinely understand the behavior of a program.

So what, pack up and go home? No... just take a different approach. Like the auto mechanic's approach.

I don't know everything about my car's engine, but I know when its making clunking noises... so I know something is wrong. So I take it to the expert. He tinkers, and then claim its fixed. Working as designed. How do I know its fixed? Well, if it doesn't clunk anymore, any nothing else behaves out of the ordinary, then its fixed!

We need a similar model for software. Specifically, the non-technical customer should be involved in the test plan, not the code design!

This idea came to me after reading an interview with Dave Thomas, the well known Ruby guru. His company was hired to create an application for British Telcom using Telexes. Now, the management didn't understand anything about the code. They didn't use UML, Rational Rose, or anything like that, and yet they were 100% involved in every one of the thousands of features in the product.

How did that work? Well, Dave created an extremely detailed specification for the product. The spec contains names of methods, and info about what it would return when asked to process specific requests. They took that spec to his bosses, who suggested changes, and made additions. All the while, another team was writing the code with the currently available spec.

At the end, when the management was satisfied that the spec was complete, he ran the spec itself through a custom application. The application extracted all the information about what method should output what data, and turned it into an automated test!

You see, the specification was in a very special format. It not only contained the description of the behavior, but also machine-readable data that could be turned into test code. Every single feature in the spec was automatically testable!

If they changed the spec, then they would run it through the test generator again, and re-run the test. The first run would naturally fail, because the new features aren't there. The developers would then keep working until the test suceeded.

In this way, the management had 100% control of the behavior of the application, but the developers had 100% control of the implementation.

Everyone's a winner!

That method, in my opinion, is the best approach... and I'm surprised that more people don't do it.