love this explanation of the importance of specifications - from joel spolsky in a salon.com interview*
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. …
…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. …
…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.
and this bit on web vs. desktop apps:
There's a couple of other issues which would be nice to solve. One is to give you a way to work offline in limited circumstances. Let's say you wanted to make Gmail, but Gmail where you could actually take it on a plane and work offline, read your e-mail and send e-mail, queue it up for delivery. And so somebody could develop some kind of standardized system for doing that kind of offline work.
Adam Bosworth has been working on this a lot -- we'll see if anything comes out of that, now that he's at Google. That would be cool.
But the funny thing is, Bosworth has been talking about this same problem for a long time -- he's just obsessed with the person on the airplane. And, lo and behold, airplanes are actually getting Internet connections. And Wi-Fi is spreading like crazy. What's kind of surprising is that it has turned out to be easier to rewire the entire world for high-bandwidth Internet than it is to make a good replication architecture so you can work disconnected! It's actually far more likely that this problem will be solved that way, oddly enough.
* subscription or free day pass (watch an ad) required.