Software Development

Here's a little cost trivia for those that believe in the No Silver Bullet theory. This quote can be found here as one of the question how many workers died in during construction of the Golden Gate Bridge.

Until February 17, 1937, there had been only one fatality, setting a new all-time record in a field where one man killed for every million dollars spent had been the norm. On February 17, ten more men lost their lives when a section of scaffold carrying twelve men fell through the safety net.

I'm going to quote one part again.

where one man killed for every million dollars spent had been the norm.

From this point on, anything that has to do with software is trite. My point is that we could start off with high costs and then bring them down. We don't need to. It's already dirt cheap to produce software compared to many other fields.

So all that's left is to say that it's so cheap in fact, that we cannot bring costs further down. This is also pure fantasy. Brooks has four points. These four points are his claims as to why software is more difficult than other fields and why there is no silver bullet. Let's quote him.

Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.

One point, his last, is so easy to disprove, I can just link an example.

Argument 4: Invisibility

Software is invisible and unvisualizable.

Let me debunk this once and for all.

Take a look here.

That's the node editor in Blender. With a certain set of primitive components, you can build ANY software. Anything in existence. So I'm not talking about Blender the software, or how to build the node editor. I'm talking about building software within the node editor. It works. And people like using it. This point of Brooks' that software is invisible is dead wrong. It's false. And it should be done with once and for all. People used to say that we'd never use graphical GUI's because text was so much faster and took less memory. Brooks says the screen is too small. Tell that to the people that make Blender and Lightwave.

We've just debunked 25% of Brooks' argument. I hope this part was clear. I must also mention that what you've seen here with nodes is NOT a flowchart. It is data flow. It exists in the spatial dimension unlike flowcharts that exist in time. Software existing in the spatial dimension is something that Brooks incorrectly says is not inherent with software. That picture proves him wrong because that picture exists and works. So while Brooks argues that describing execution in a visual fashion does not work, this says NOTHING about data flow. He uses execution to make an argument for data flow. You can't do that. This is the kind of argument lawyers make.

3. Changeability

The software entity is constantly subject to pressures for change.

Somehow, we are supposed to believe that software changes more than things in other fields.

This point is so ridiculous, I cannot fathom how anyone could have thought of it.

Buildings do in fact get changed, but the high costs of change, understood by all, serve to dampen the whims of the changers.

Brooks' debunks himself. I shouldn't have to say anything about this, but here goes.

If there's something wrong with anything you build, you want to change it. It doesn't matter if it's hardware, software or whatever else. Just think about game cartridges back in the Nintendo days. You couldn't just send out a patch if you were one of these developers. They wanted to. But they couldn't. Even for faulty components. A callback doesn't happen often because of what Brooks says, it costs too much. But it's not because they don't want to send an update.

Over the years, software has been able to reduce costs of duplication and update by an unimaginable amount. Today, we have things such as free packaging and installation software. We have patch software. We also have automatic updates.

In all fields, new releases happen. So in all fields, there are costs associated with this. Only software can increase the amount of releases because costs have been brought down so much. But the development of these new releases must happen in all fields. So that cannot be Brooks' point. The hardware field doesn't stay idle in between releases.

Change is not a disadvantage. Neither is it an increased cost. It's a benefit and you will reduce costs and loss of sales if you can fix things quickly and easily. I hope this argument about change dies quickly and easily too.

2. Conformity.

This one makes me laugh. Brooks debunks himself here again.

These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God.

If it has to do with people, then we can come up with better solutions, so this is an accidental complexity. He even says it's not a "necessity". I'm not sure why Brooks even bothered to write this section.

1. Complexity.

So software complexity is complexity. Not sure whether to laugh or cry at this point.

This part is annoying to debunk because there's a lot of unsubstantiated claims. But I'll give it a try. We need two quotes and a shot of rye for this one.

The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.

First, he makes an assumption and then makes a conclusion based on this assumption. I have to dismiss this claim right here and right now. But for the sake of argument, let's see why the complexity of software is not essential. To do that, we must know what parts Brooks believes are essential to software. Luckily, he mentions this earlier on. Let's look at that.

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.

I have no problem with data sets and relationships among them. But algorithms and invocation of functions are not essential to software. Look at the Blender example, there are no functions and no algorithms. Done.


All four points have been debunked clearly and concisely. Ironically, Brooks debunked two of his own points. I really hope that people put this paper to rest. And if I wrote this article in a somewhat mocking way, it's because this paper has been an evil joke on all of us. There is not one bit of proof in the No Silver Bullet paper. Not one. Even the anecdotal evidence is wrong. In many cases, he uses evidence for one thing to argue for something unrelated as he did with dataflow. The only thing he's perhaps done is argue against functions. I find it odd that the people who use functions are the very people who support the No Silver Bullet paper.