Site Presented By
Sunday, Nov 22, 2009
Can you look at software development today and say, "Things will continue the way they are, it's just the nature of the beast," or is there some --
Silver bullet?
Sure, silver bullet, or just some elephant in the room that we haven't seen yet about how to do things better.
You're familiar with [Frederick Brooks'] "No Silver Bullet" article. That's a pretty strong theme. But it's not like Gödel's proof, like we now have a proof that there's no silver bullet.
In some fields you do reach a point where there's a giant leap of some kind that changes the way people work and think.
There have been a couple of quantum leaps in the history of programming, possibly three. But they're not the things everybody thinks.
First of all, there are a lot of people who say they're going to invent some new thing where the business manager is going to specify what they want the software to do and it will mechanically translate that specification, and brrrrt! The trouble is, this is a perpetual-motion machine. We keep inventing it, keep making companies to ship it, they're always wrong. The fundamental problem that you're trying to solve here is that humans think of things in vague, mushy terms. In order to visualize something, they don't have to actually visualize every part of it. Whereas the programmer, in order to actually implement that thing, to create it, needs to have every part specified.
So you can imagine an airplane without even knowing what a rudder is, yet without a rudder an airplane's not going to work very well. Partially that's just the way the brain works. The brain is totally optimized for just looking at one thing. Just think about how the eyes work. When you're looking at the world, you imagine that you have an extremely high resolution, extremely large screen full of billions and billions of pixels in front of you. Yet actually your eye has, I don't know how many, but under a million pixels. And what's really happening is, you're just moving your eye a lot. And your brain is filling in the rest and pretending. Because you can move your eyes so fast, anything you want to see you can see, and anything you want to focus on you can focus on very, very quickly.
So your brain doesn't actually work the way a computer works. Your brain doesn't assume that there's all this input coming in and then process it. Instead, it just has a variety of senses available to it, and it picks the ones it wants to answer whatever questions it has right now. So you ask questions, and your eye goes and finds out the information it needs. So you're used to thinking that you have the big picture, and you don't.
And with software, as soon as you start talking about how the pieces are going to fit together, you discover that the things you were imagining are going to be completely ambiguous or impossible or contradictory -- instead of being as simple as you say.
One of the biggest mistakes you can make in developing software is to say, "I'm going to build this thing and it's going to be super easy to use because it's going to be super simple, it's going to be unbelievably simple." And then you say, "OK, how am I going to do footnotes?" Oh, well that'll be real simple -- you just ask for a footnote and you type a footnote, and it'll just be there. Well, what if the footnote is too long to fit on the page it's currently on? Um, I don't know -- maybe you have to move part of the footnote onto the next page. Suddenly, it's not so simple.
As soon as you start to think about how to get everything to really, really, really, really, REALLY work, it becomes much more complicated. So software starts out with a simple vision and it grows a million little hairy messy things. And depending on the quality of the initial vision, those hairy things may be more or less hairy, but they're going to exist.
And therefore, because software seems so simple and is actually complicated, you can't implement it until you specify the complication. And all these people that are trying to make the same perpetual-motion machine -- where you just write your specification and it automatically becomes code -- don't realize that the specification has to be as detailed as the code in order to work.
In order for it to be translatable into code, or in order for it to become the code.
Right. Isaac Bashevis Singer, I believe, wrote in Yiddish, if I'm not mistaken. But very few people ever read him in Yiddish. The first thing that happened to almost everything he wrote was that it was translated into English. And so it's almost as if the goal is to create an English-language short story, but you can only write in Yiddish. And you're going to really have to write the whole story in utter detail, and then it will get mechanically translated.
But now somebody tells you, No, don't even bother writing the story in Yiddish -- just tell me what happens, and I'll write the story for you in English. Just give me the gist of the story.
So you say, OK, it's gonna be sort of a love thing, in the shtetl, in Eastern Europe. The guy is a young man, he's enthralled with the Communist Party. The woman is sort of a traditional Jew from an Orthodox family, and so her father is not very happy with this guy. Make a story out of that. You can't. It's not enough of a specification. You've got to tell me the guy's name; you've got to tell me what he says and what happens. Otherwise it's not a story. So because there's this last-minute phase in which the Yiddish is translated into English, that deceives people into thinking that you could translate anything into Yiddish, including your ...
Hold on, I'm trying to follow the analogy here! The Yiddish is the equivalent of ...?
The Yiddish is the C++. The English is the machine language code. Just because there is that compilation stage doesn't mean that the C++ level, the programming language level, doesn't actually have to specify everything that's going to happen. And so what a programmer is doing when they translate a quote unquote spec into quote unquote code, although it seems like a translation process, what they're actually doing is filling in lots and lots of details. And as programmers are wont to do, they're trying to take something, the vague thing that the humans want, and make it very, very specific, which is the kind of thing the computer wants. That's not really a translation; it's more of an interpretation. It's a very hard thing to do.
The perpetual-motion machine is where you say, let's just take these business requirements that some business guy came up with and suddenly, instantly make code from them. And that doesn't work, because the business requirements don't actually specify what to do with the footnotes when they run off the bottom of the page. And the computer's going to have to know.
You're saying there's a ton of work between the general requirements and the detailed specifications.
There's requirements, specifications, code -- there's many levels. If you think of the requirements as being this paragraph, and the specification as being this page, and the code as being several pages, at each point, you're adding more detail. And in fact you can go straight from the requirements to the code, and most people try to do that. The trouble is, it's like eating your meat without chewing it -- you tend to choke a little bit. Whereas the specification is just a hope that before you actually start on the code you can think of as many problems as possible and solve them when it's still easy to make changes, before you get into the code and it's more costly to make changes.
So there are a lot of false messiahs in the programming world, which is where the "no silver bullet" concept comes in. On the other hand, there have been big steps forward in productivity; they're just not as exciting as people think.
Fortran was the first one, where the idea was you would actually write out your equations, and you would be able to write formulas, you know, (I+J) x 2, as opposed to writing LOAD 2, LOAD I, multiply, blah blah blah, in assembler language.
The second thing was Algol, the first procedural programming language, where the idea was you could actually group concepts of subroutines and functions and pieces of code; certain things like the "while" loop were invented, which made another leap forward, in that code could become that much more abstract and modular. A lot of people at this point would add object-oriented programming as a big leap forward. I just don't include it as a leap forward in productivity. I'm not saying it's a bad thing, just not as big a leap as these other things.
And the third big leap is what they call the memory-managed languages. Languages with either garbage collection or with reference counting or some other mechanism so you don't have to decide where memory comes from.
