Slashdot Mirror
Linus Says No to 'Specs'
auckland map writes to tell us about an interesting debate that is being featured on KernelTrap. Linus Torvalds raised a few eyebrows (and furrowed even more in confusion) by saying "A 'spec' is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality."
Linus is an engineer/tech. He dislikes theory work because it often gives nothing in practice.
However, specs are not always theory, and they may be usefull, as well as docs. He may be smart enough (or know linux code enough) to not need any doc/spec, but it's not the case of many other people. Some specs are good, and sometimes necessary.
He cited OSI model, well, but I can assure you I won't go in an airplane if it was done with Linus' practices... There are specs in some places that are good, and that are read and followed. Even in non-dangerous domains such as Web standards, specs are necessary, and those who don't follow these specs make crap softwares/browsers!
Moreover, in Linux development model, which is fuzzy and distributed, not directed, defining the software may be vain. However, in a commercial environment, defining the spec is really writing a contract, which protects both the customer and the editor. Specs there defines what the software can and must do, and ensures it will do. Linus obviously lacks of experience in industrial and critical projects. He may be right for the kernel development (however I still doubt it should be so entire on that subject), but he's wrong on many other domains.
IOW, Linus does here a generalization which is at least as wrong as are the examples he cited. As we say : "all generalization are false".
If he finds a bad spec, either it throws it away, or he fixes it. It's the same for technical docs. But he shouldn't tell every specs are useless and bad. That's wrong.
How are you supposed to write software which interoperates with other people's software without relying on a specification to define the interface? I have read some of the thread and I really can't understand where Linus is coming from here.
The whole discussion was centered around implementing specs. And the point made by linus was that one should not implement specs literally, not to structure the software as the specs are structured. He did not say the software should not adhere to the interface given by the specs. So the software should work like specified, one should just write the software in a form which makes sense for the larger scope of the software, not one limited to the scope of the specs.
Also having a documentation will keep the leader itself on the correct path and not stray from it's original design.
It is extremely rare that the original design is the correct path.
I believe posters are recognized by their sig. So I made one.
Specification documents are the only thing in the company I work for that stops customers asking for functionality in the 11th hour of development, claiming that "they always meant that it would have that" or "I thought I mentioned that at the first meeting".
As companies go the one I work for is pretty lax with documentation, but they are very careful that all customer requirements are listed iteratively, and - more importantly - signed off on.
I have been in situations at work where for whatever reason a specification hasn't been drawn up for a customer; its either been left to informal emails or in the worst cases word-of-mouth/notes written in an initial meeting. In my experience these often end up running on past their deadline as the customer requests more and more esoteric functionality, or design and presentation tweaks that covertly require additional functionality, etc.
As a rule of thumb as a die-hard programmer I hate documentation, particularly detailed technical specifications which constrict my creativity. That said, where it is necessary I absolutely see the need for it - how else can you constrain the customer to what they originally asked for?
I once worked on a Standards-writing subcommittee, and ended up being the editor of a proposed standard. I was new to the process at the time. I took the work that was done and completely re-wrote it, from the ground up, according to the published guidelines of the Telecommunications Industry Association (TIA). I then presented my work to the subcommittee.
"It's too clear. People might actually understand it." I argued that because it was a specification for testing, it should be clear. Yes, I won the argument, but at what cost?
Over the next few years I watched as more standards were created, edited, published, submitted to the ITU, and eventually turned into Recommendations. When I asked, "what does this section REALLY try to say?" I was told that in order to understand that section I needed to know another piece of the puzzle that wasn't spelled out but was "understood" by "practitioners of the art." In other words, the specification was incomplete...but not according to the rules. I asked why. The answer I got boiled down to one thing: you can't implement the specification without the "stories around the campfire" behind them.
Put starkly, you can't play unless you join the club.
Now, in reality, people have taken these less-than-complete specifications and actually made products with them, products that successfully interoperated with those implemented by members of the club. The development time, however, was extended by the need to discover the missing pieces on one's own, or to buy the missing pieces.
Then there was the story of what eventually became V.80, which I discussed in a Slashdot interview. That particular standard proposal was so bad that I had to vote "no". Again, I ended up rewriting the entire thing so it made sense, and in addition covered not only the corner cases but also future extensions and vendor extensions. It took DAYS to prove that the two versions said technically the same thing (within limits). You could code to mine; the other was almost impossible and "open to interpretation."
Most specifications (or Standards) are written by partisan participants. It's to their best interests to write these things so that outsiders can't understand them -- be it commercial gain or personal ego. Good spec writing is HARD, and not for beginners. It takes work. It rarely pays anything to write a good specification, especially if the writer views it as a pro-forma task. Just as programmers from several decades ago viewed flow-charting as a useless task.
Just as people are starting to view Open Source not as a way to lose money but as a way to gain money, perhaps the partisans will see that writing clear, understandable, WORKABLE specifications is in their better interest....or not.
Given the current state of the art, though, I would tend to agree completely with Linus that specifications, and Standards, that don't provably track with reality deserve not "no", but "HELL NO!"
Its an idiot who says a spec is useless. Perhaps a 400 page IBM corporate spec on a filesystem is useless, but 20-40page specs are not.
/* comments, so its damn easier to read and visually see, 100% ascii blows
Hashing out a spec at least shows you what can be possible and what cannot, and while doing it, you may
see possibilities of new features or addons and also you might realise that feature X will take damn ages.
It also shows you that feature Z might ruin your whole design or be nothing more than a timewasting experiment.
There are different levels of spec design, but im not saying, go make it ultra low level. Jeez Linus, even doing a rough
diagram of a gui or this process does step 1 thru 12. At least the other developers on the team can see what in hell
your are going to make. Not just some 1 liner, "we're gona make a kick-ass 64bit indexed image engine/database"
How about a 200 thread level async dns resolver? Oh yeah all in your head Linus.
Heres my product spec for a better IDE in 1 line.
Support basic html inside
man. Even support IMG tags so your can BUILD in documentation thats usefull in your source.
High level specs, yes, lowlevel specs that are 5x larger than source codes, NO.
Liberty freedom are no1, not dicks in suits.
Maybe "what works" is the best approach, especially for an open-ended project like Linux.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
If the theory does not match the practice, the theory is incomplete. In other words, fix the theory. Don't make vague and stupid generalizations against it. Those generalizations are nothing more than rationalizations for the sake of the idiot makeing them.
Yes, you are right... in theory.
I write software to spec. In theory, that should work. In practice it often does. But often there are gaps in the specification that the guy spec'ing should have seen, but didn't. Perhaps, his kids woke him up 20 times last night, perhaps someone made a bad pot of coffee.
These gaps in the spec become glaringly obvious when writing the code and in the iterative component testing. That's the practice.
Now, if you invest 5 times the effort in the specification, you can probably get it all. But in practice, it's often better to prepare a rough, incomplete functional specification. Make a special effort to specify the interface between interacting parts of the system, especially if they are developed by differnt teams. Then allow the developers more scope to communicate and modify this in the development process.
I'm not saying this is a good idea for building spacecraft. But it makes sense for commercial software development.
"software was written to match theory, not reality"
That was very blinkered and unfortunate statement by Linus. While he portrays himself as a "practical engineer", the truth is that he is not flying the flag of professional engineering, but supporting some kind of ill-conceived ideal of ad hoc amateurism.
The world of computing is in crisis. After 40 years of 'pro' development, computing is still a human-driven craft instead of the extremely precise arm of engineering that it could so easily have become through its well-defined subject matter.
While Linus has contributed immensely to the world by delivering a wonderful engineering tool as well as a great end-user product, he is also extending the software crisis through unfortunate remarks like that one. The "reality" which he so seems to praise is THE PROBLEM in software engineering, and not something to be endorsed or supported.
If the world continued along Linus's desired path of "reality" vs theory, the current mess will know no end, and the metaphorical bridges of computer science will still be falling down in the year 3,000.
Mankind's future in computing must build on immoveable foundations of theory and logic if it is to progress into a realm where machines of IQs in the millions work at our behest. Advocating some sort of ad hoc "practical" computing barbarism is very short-sighted, dangerous, and regressive.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Alternatively, maybe you could wish that the fuckwit coders who gave the thing to you had read the documentation and done a little testing to make sure that it works according to the docs, instead of changing things arbitrarily without telling anyone.
All that "my code is my design" bollocks is just that - bollocks. I can spend a week reading code to find how stuff actually works, or I can spend a few hours reading the spec that says how it *should* work. My job is *not* debugging someone else's shit code, my job is writing something that uses or interfaces to their code. If they've not done their job properly, why should I be expected to be the one to find the holes, just because they can't be arsed testing it properly?
Grab.
I can see where Linus is coming from; on the other hand, I can see where the statement is fundamentally flawed. The best example I can give is a 3D engine. I have worked on an OpenGL engine for almost 4 years now, and certain aspects of the engine development (namely shader architecture) were purposely left without a formal 'spec'. 3D Hardware changes more rapidly than one can build a 3D engine from scratch. If the entire engine followed a 'spec' from day one, it would be obsolete by the time it were finished. If you had asked someone four years ago what NVIDIA and ATI would be working on right now, they could never guess that vertex and pixel shaders were beginning to merge (both on the hardware (shared pipelines) and in functionality (pixel shaders have front/back face information and vertex shaders can perform texture lookups)). They could have made assumptions that caused them to code themselves into a wall so to speak and which prevents them from ever utilizing the features of Shader Model 3.0.
On the other hand, there are other teams who work on gameplay and network development. For the most part the network developers can develop a 'spec' and reasonably follow it. The gameplay mechanics follow a constantly revised 'spec', and probably the only one the consumers who play the game are ever familiar with. In this aspect of development, a 'spec' is _required_ to complete the project in a reasonable timeframe.
I think there's a lot of confusion over the word "specs". That can mean a few things for software:
:) It shouldn't be too complicated, but the purpose of these kind of "specs" are often mis-interpreted by "pure analysists", what in some cases ends up in a way to detailed almost pseudocode alike book. This is BAD, by theory leaves no room for interpretation, but in practice it does. The person who wrote this could have written the code instead - and would have found all contradictions, errors, and would have been faced with all practical problems his "point of view" suffers from.
:) Basicly these are nothing more than a written down version of good and clear agreements. If reality changes - these should be changed, never the other way around, but which happens way too much.
:P)
:p
1) What the program should and shouldn't do. These can be "demands" from the customer. Should be non-technical, not too detailed - but should be clear. If the customer has specific I/O demands, this should refer to other documents for this, don't mix these things.
2) Internal software analisys. Should describe the internal main blocks, in most software companies I've worked, this is done on a blackboard with all important dev's there brainstorming about a project. If it gets really complicated someone might be victimized of putting that on paper
Sadly enough - these kind of specs (in general) usually end up way too detailed. Programmers always have their "speciality" if they are left with some freedom. Let them do their own thinking give them an "IO spec" for their part - and let them do their job. At least that's what I do, I don't want code-monkeys in my team - I want individual coders who actually understand what the hell is going on. Too bad they're becoming harder and harder to find. I blame Visual Basic *grin*
3) An I/O or interface spec. What goes in and what goes out, described in what form, as short as possible, with flexibility so someone can easily add a proposal/extention to it. These are not easy to make, but luckily I work in a competitive team that understands software writing
These are 3 completely separate things. All 3 need to be done more or less for major projects, some can be left out. Mixing these should be avoided as much as possible. The first 2 I consider to be "software specs", the last-one is something completely different and I see a lot of people here confusing these. HTTP, TCP/IP, HTML, XML, XHTML, RSS and even POSIX aren't software specs, these are standardized I/O / interface specs. Such specs are in general a good thing, they describe how something should be used, so multiple programs can "communicate" with each other using the same interface.
As far as I've seen, writing software to specs is an utopia. The worst specs usually are specs written to an existing program. It's fine as "documentation" and shouldn't be used for anything else, certainly not for writing a new version. Writing detailed specs after a project is finished (well - as far as that's possible) usually has little point. Writing documentation on the other hand has a point, but this is widely regarded as a boring unimportant job (and I can't blame anybody who does
Anyway - what I suspect that Linus means is a mixture of these 3 - a mess which mixes everything in a way to detailed form. Most specs that are written are plain wrong, bad, and mix too many things. Most of the software specs are written by people who think they know everything. Nobody does.. except me offcourse
We wrote the Open Graphics Project spec not based on purely abstract theory but based on the experiences and needs of the community. Purely for the sake of survival, I made it clear that there should be nothing in the design which could not be justified by common needs. Based on that, we developed a SPEC.
Maybe Linus is having a language-barrier problem, but a spec is just a description of something, albeit somewhat formalized. That means you could write a spec retroactively. We could write a spec for the Linux kernel as it is right now. If we were to do that, would Linus abandon Linux? It wouldn't be THAT hard to make it accurate.
Frankly, I can't write anything without SOME sort of spec. Often, those specs are contained completely within my brain, but I nevertheless must develop a coherent concept of what it is I'm going to build and what its pieces are. When I write a document, I often start out with some sort of outline. And when I write code, I have to decompose it into functions.
If a spec is any coherent description of something you make, then Linus uses specs all the time, and he's just blowing smoke out his ass.
He's complaining about specs because they're usually done badly. JUST ABOUT EVERYTHING IS USUALLY DONE BADLY. Should we say that all operating systems are bad just because Windows sucks? Should we say all cars are bad just because the Ford Taurus is designed to last only 5 years? Should we do away with TV just because of shows like "Two guys, a girl, and a pizza shop" or "Survivor"?
Linus is forgetting that Linux is based on specs, Honda makes reliable cars, and Star Gate SG1 is on on SOME channel just about all day.
This is obviously the rant of a person who has never programmed for an actual client (a human one). 99% of the time a spec is the understanding between the user and the provider, whoever they are. So yes, Torvalds is right that they are mainly for talking about software, but unless you are writing your own operating system on your free time, you have to be able to talk about it or you will implement something other than what the client thought they paid you for, and then they get sour. Specifications are about understanding and communication, when not the whole universe is inside one person's head.
Moreover, Torvalds doesn't really seem to know what science is. There just is no criterion that a scientific theory has "no holes." It doesn't work that way.
From what I read, it seemed like people were trying to get him to soften his stance on that, and he seemed pretty adamant that he hates specs in any form or fashion.
Of course, it's easy to do that when you're Linus Torvalds, and whatever you say/do is the de facto standard without the need to write a spec. He's basically a walking spec. However, I'd invite him to consider what would happen if all the peons adopted his theory. Nothing would interoperate with anything else.
The only thing I can think of is that he defines a spec as something that is inherently written once, before implementation begins, and is strictly adhered to no matter what. However, I don't think any sane person would agree with that definition, I can't imagine that's what the other people in the thread meant by the word "spec," and I can't believe he'd imagine anyone else defending such a process in the first place. So I do believe that Linus is being a bully again.
If specs were 100% accurate, then there would not be a need to write the code, because the specs could be automatically translated to code (we are talking about 100% accuracy here, not 99.999999%).
This is not true in general. It's quite straightforward to spec out a program that solves the Halting Problem, for example, but rather harder to code one. And there are issues to do with optimization and so forth that would not appear in a specification.
Nonetheless, there's a great deal of truth in what you say - for most real-world programs, a 100% complete formal specification of what they had to do would not be much shorter than the program itself. This is why agile development methodologies make sense.
Xenu loves you!
"Rules are there to make you think before you break them."
Simple expertise is knowing the right thing to do. When you go beyond that to knowing when its the right time to do the wrong thing, then you have mastery. So, when somebody who has years of mastery of a craft says, "the rules are crap" it has a different truth level than when somebody who's merely competent. The difference is the way the right thing to do is backed by unspoken, unarticulated working knowledge in one case, and mere bravado on the other. I can do basic carpentry, but the difference between me and a master cabinetmaker when building a book case is that I have to keep referring to my plans, whereas the cabinetmaker, while he may have plans, operates more unencumbered by them, moving quickly and confidently because he's internalized longer sequences of operations, until he can see the whole construction process in his mind's eye. When I don't worry much about my plans, I end up with a dado on the wrong side of a plank.
Being "against specifications" of course is stupid. But Linus is in an unique position to be a bit cavalier, isn't he? Specifications do two things. First, they tell you what needs to get done. Second, they communicate this between parties, say the specifier and implementor, the customer and contracter, the builder of tab-a and the constructer of slot-b. But Linux is, if I understand this, a pretty conservative implementation of an existing model, where innovation where it occurs is fairly contained and focused areas. And as far as Linus and the Linux kernel is concerned, L'etat c'est moi. He may well have managed all these years keeping what needs to be done in his head, and the result could still have more coherence than the product of a well coordinated committee.
The other thing to keep in mind is you can't trust everything anybody says is categorically so, even when that person is perfectly honest and sincere. The simple reason for this that mosts truths have an element of fuzziness in them. In limited circumstances it is sometimes necessary to hold what is, in general more false than true, but in this case more true than false. Wisdom is knowing when and how much to doubt what you believe, or believe what you doubt.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Why should I be expected to be the one to find the holes, just because they can't be arsed testing it properly?
Usually you shouldn't, however you will. It doesn't matter if you're creating a web browser that can't display "broken-but-renders-on-IE" webpages, an IDE driver that may corrupt data on "UDMA-compatible-but-not-compliant" hard drives, or a server process that crashes on corrupt or malicious out-of-spec data: as long as your code is what's interfacing more directly with the user, your code will probably be blamed for the problems. In particular, if one of your competitors has found and worked around the holes, your code will definitely be blamed for the problems.
It's not fair, but it's life: from a user's point of view it's easier to get new software than to communicate with a different set of people or buy new hardware.