in Management, Strategy, Systems

Still no silver bullet

From the time of publication of the essay “No Silver Bullet” in 1986, we have been looking for the silver bullet ever more diligently.  Even the essay’s author, Dr. Fred Brooks, Jr., wrote a sequel called “‘No Silver Bullet’ Refired” that appeared in 1995. On a less grand scale, five years later, I gave a sad keynote address at Software Methods and Tools 2000, a part of which was a prediction that project management would become another failed silver bullet in this century.

Sadly, all of the above predictions have turned out to be true.

The silver bullet we claim to want is the concept of “reusable parts” — not reusable code. While IT is super-saturated with bad analogies, there is a good analogy for this particular quest. If I am building my dream home from scratch, I would not be forced to build everything in it from scratch. I would figure that the house is 2700 sq. ft., in Virginia, well shaded from the afternoon sun, and I would order a 3-ton air conditioner from Lennox rather than build such a unit starting with the copper pipes. If nothing else, I am even less experienced building air conditioners than houses.

That’s what I want when I program: something standard.

In IT, this was once called “shrink wrap re-use,” meaning that for things like databases, my choice is simply to go down the list of available pre-built parts and choose Oracle, MySQL, SQL Server, SQLite, or maybe even DB2. No one should think seriously about writing a database from scratch just because the end product requires the use of one, and indeed, no one does. Unfortunately, this type of component-level reuse is scarce.

We are now fighting a war over libraries. For example, jQuery is library. .NET is a library. A review of my staggering number of searches of in Safari’s history reveals that PHP is almost entirely a giant library, at least the way I use it. More than 60% of the lines of code in my C++ programming are function calls of some variety, and I think most of the rest consist of basic assignments. I hear Ruby is the same. And Python, too. Libraries can be simple.

Does this truly and finally give us the victory we want? Apparently not. When working as a consultant, I primarily look for work doing Linux/UNIX server-side development, often in C++. “Interview” questions about C++ are completely standardized to the extent that there must be a C++ meme going around. The questions generally involve some sort of cursory interrogation about the STL (Standard Template Library), which is an enormous part of the language.

When it is my turn to ask questions in the last 30 nanoseconds of the interview’s time slot, I often ask what the company does with the STL. Inevitably, the answer begins with how they do not use it despite the interviewer’s having spent several minutes gauging my familiarity with the subject. How often does this happen? Almost every time it is discussed.

But in the past two or three years I have never heard a specific complaint backed with an example. No one volunteers an anecdote of a particular problem, its negative effect, and explains their solution. You would think that if the perceived problems were real, common, and well substantiated that someone on the GNU project would have repaired the STL by now. It is even harder to believe that the repair involves an odd difficulty such that [a] only people who are not working on the STL can write the code, and [b] none of the people working on the STL are motivated to do so.

So why the constant re-engineering? Of course, there are some reasons to grasp for every efficiency possible. For example, I recently popped in ten lines of assembly to speed up a string move that was being done 2500 times in a loop, and I shaved about 10ms off an 80ms task by doing so. But did I feel the need to re-write, pre-bug, re-bug, and re-debug <std::string>? Of course not.

I suspect that the majority of re-engineering of standard libraries comes from feeding programmer egos, after all we call them “programmers” and we expect them to “program.” The second most common cause is programmers doing a bit of that thing that dogs do because they can, just like many test plans conduct tests on the most obvious parts of a product rather than the ones that are difficult and need our attention.

“Will a brass bullet do?” This was the title of one of the sections of Brooks’ second Silver Bullet essay, and it is attached to the section on object oriented programming. Lately, I have had some reason to hope, but not for OOP. Instead, JavaScript, and more specifically jQuery, provide tight, well written libraries with two important features that have been missing from previous “shrink wrap” cases: [1] It is clear how to add something to the jQuery library rather than rewriting parts of it. [2] It is possible to distribute the plugins (additional jQuery library code) without disturbing the original.

I guess I am willing to live with the brass bullet, but I need a belt of them.