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.
I heard he had good vision. --(o)~(o)--
Who was it that said:
In theory, practice and theory are the same. In practice, they are not.
Linus has spoken.
..big _YES_ to underscores.
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.
Bill Gates says "Beta testing is for sissies".
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Who is this Linus guy anyway? I bet he's never managed a software project of any complexity.
Personally I've found specs to be incredibly useful. I'm currently developing a middleware project that takes a complex search pattern and applies it to a streams of delimited character objects and while our team of 40 software software engineers has yet to actually start developing we've produced a fantastic spec that will greatly simplify coding it.
I suspect we'll have this general regular expression parser up in running in less than 80 man years of effort thanks to our full and detailed specs.
US Citizen living abroad? Register to vote!
Linus does code to specs: the kernel is intended to comply with all sorts of formal and informal specs, and its developers pay attention.
What is missing is people writing and committing to specs for some important kernel internal interfaces and functionality. This attitude goes hand in hand, of course, with the lack of stable internal interfaces within the Linux kernel and is one of the major reasons why the kernel source has bloated to such a humungous size and why every kernel release needs to include all the accumulated garbage of the past decade. If internal kernel interfaces were specified and committed to for each major version, then driver and module development could be separated from the rest of the kernel.
Of course, Linus is right in one area: most specs are useless. There are two primary reasons for that. Either, the spec is poorly written; there are lots of those. Or, the spec describes a bad design; there are many more of those. Many of the original UNIX design documents were exemplary specs: they told you concisely what you could and could not rely on. On the other hand, many recent standards (like HTML or SOAP) are examples of well-written specs that are bad specs because the underlying designs suck. But the fact that many specs are bad doesn't mean that it is inevitable that the Linux specs would be bad; that only depends on Linus.
At a conservative estimate, I've pissed away half of my lifetime development effort dealing with instances where the documentation of an OS, APIs or SDKs doesn't match the actual behaviour. Every time I get sandbagged with that, I wish I could just read the damn source and see what's really going on.
Linus is quite right that a spec can be useful as a descriptive abstraction, but not as an absolute or proscriptive definition. When you're sitting there at the keyboard and hit a point where the behaviour differs from the spec, it doesn't matter why the spec is wrong, just that it is. Red pen it and move on.
If you were blocking sigs, you wouldn't have to read this.
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.
Predictable code is good code. You want your code to do x when y happens, and everyone who relies on your code should know what to expect from your code under every circumstance. Kernels are supposed to be boring.
Specs may suck in some cases; if they do, they're badly written. It's an indictment of the person who wrote that spec, not the concept of specs in general. When I call a function, I expect it to do exactly what its documentation says, and it should comply with the documentation exactly.
I shouldn't have to read the code just to use it. That defeats the entire purpose of segmenting things out into separate pieces. You might as well be using gotos to write your spaghetti code.
Remember, there were no nuclear weapons before women were allowed to vote.
"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
From one of my past lives, when I designed computer systems in automobiles, before my current stint as a grad student, I can describe how we used specs. Some of our business folks who had some basic training as engineers would get together with our customers folks who had basic engineer training, and hammer our a 100+ page spec document covering everything from basic operating precepts to acceptable failure modes. They would use this document as a means of discussing what they thought they wanted to buy, and what we thought we could supply for them, and then determine a cost from this proposed spec.
After enough words had been passed back and forth, both sides would agree on a version of the spec, money would be passed around, and hardware design engineers and software engineers from all over the world would get to work. At this point, the spec would be skimmed, people would get a rough idea of what everyone wanted, and a couple hundred of the first prototype version would be cobbled together.
Testers and verification people on both sides of the fence would look at this thing, first against the spec and make sure it included everything that was talked about, and then in the system to make sure that it would work they way they needed it to. This is the closest that the design ever got to the spec. After this point, everyone would start noticing places where the spec was either too rigid to be followed cost-effectively, or just plain wrong for our customer. Since rewriting a spec is a ton of work, it never got done, and in the end was just a basis for verification folks to look at the design and complain that it didn't work they way that they thought it should. I guess someone should have included them in the "cool peoples idea passing club", but, neah.
This article isn't about a general comment as to how software should be written; it's about implementing protocols. And protocols have to be defined by specifications -- you can't simply have some vague spec that says "it should do approximately this"; you have to precisely define the language of the protocol so that everyone knows what they are implementing.
That being said, Ted Ts'o makes the most important comment in the discussion: This is the reason for the IETF Maxim --- be conservative in what you send, liberal in what you will accept. In other words, when your code talks over the protocol, be minimalist and adhere strictly to the spec; but if you can implement your code in such a way that it is tolerant of small variances (e.g. combinations of commands which make sense but are not allowed by a strict interpretation of the protocol spec) and can do it safely, then you should. This is the approach I've always taken, and having done things like implement a major printer vendor's IPP server, I have found this approach makes interoperability and compatibiltiy a lot easier and less painful to achieve.
So at least from that standpoint, I think I can see what Linus is trying to say; at any rate I agree that strictly adhering to a spec simply for reasons of mathematical correctness is not always the most productive route.
I have been working with specs-driven projects for the most part of my professional career, and I can tell you that Linus has a point.
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%). But specs can realistically never be 100% accurate...it is the missing part from the specs that causes headaches.
For example, I have worked in a project that required conversions between coordinate systems: UTM to geodetic, geodetic to local cartesian, local cartesian to target, etc. The user expected to edit UTM coordinates in the GUI, but the specs for UTM coordinates where never mentioned in the Software Requirements Specification. So we searched the internet, found out what 'UTM' is, and coded the relevant functions.
You know what? the specs talked about UTM coordinates, but they actually meant MGRS! UTM means 'universal transverse mercator' whereas MGRS means 'military grid reference system'. Although the concept between the systems is the same (the Earth's surface is divided into rectangular blocks), the two systems have different calculations.
When we released the application to our customer, they freaked out seeing UTM coordinates, and of course they refused to pay. Then we pointed out that the specs talked about UTM coordinates, and they (thank God) admitted their mistake, paid us, and gave us time to change the application from UTM to MGRS.
But the application has never been correct 100% (from that point on) until recently handling MGRS coordinates, because it was very difficult to successfully change something so fundamental and yet so missing from the specs(we are talking about 160,000 lines of C++ code).
Do you want another example? in the same application, the program should display a DTED (digital terrain elevation data) file, i.e. a map created out of a file of elevation data. The specs did not say anything about the map display respecting the carvature of Earth. So we went out and implemented a flat model, where each pixel on the screen was converted linearly to a X, Y coordinate on the map.
Guess what? they meant the map display to be 'curved', i.e. respect the Earth's carvature. The specs did not say anything, until the application was connected to another application that produced the video image of the battlefield using OpenGL (and of course, since it was to be in 3d, the presented map was 'curved').
The result is that the application still has some issues regarding coordinate conversions.
After all these (and many more...) I am not surprised at all that some certain space agency's probe failed to reach Mars because of one team using the metric system and the other team using the imperial system. Even for NASA that they write tons of spec and they double- and triple- check them using internal and external peer review, specs were useless at the end.
So Linus has a point...
You could at least have posted non-anonymously
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Having said that I don't think CS is a science.
... check. Political science ... check. Domestic science ... check. Social science ... check. Rocket science ... er, damn.
Yes, any subject with 'Science' in the title isn't. I forget where I heard it, but it is a useful rule of thumb.
Computer science
-- Nick "Hallo this is Beel Gates, und I pronounce weendows as
That's because Linus is talking about hardware specs. His view is that it's better to trust reality (how the device actually behaves) than a spec (how it's documented to behave). And he's right about that.
Outside the world of OS kernels there are many software projects where the 'reality' is much more changeable, much less solid. Reality in the case of a Purchasing application or your KDE/Gnome desktop applet or the latest FPS game is likely to be a case of 'what the customer/user wants'. That's something you really need to pin down. Doesn't mean it can't change but it needs to be clearly defined.
My experience getting into the kernel was usually motivated by trying to write user space programs. I finally learned what people meant when they say Linux isn't well documented.
I could care less whether there's a spec, but if I'm going to use an API, I have to know what it does. The ALSA (advanced Linux sound architecture) is absolutely the worst. The documentation is full of entries that have the form:
Now the thing I don't understand is this. If you went out to write a really big and important piece of software, wouldn't you want people to use it? What's the point of an undocumented API? It makes no sense whatsoever. You either want someone to use it, and you tell them how, or you make the methods private (i.e. not part of the API)?
Rant over.
Bertrand Russel tried to put mathematics on an immovable foundation of theory and logic, sadly it turned out to be impossible.
I don't think that you got very far with Bertrand Russell.
The higher-order issues he identified caused just a temporary hiccup in the development of logic. While undoubtedly fundamental, that problem paraphrases best as "There are hidden depths to this", rather than as "All is lost".
Godel applies, as always. You don't apply a theory outside of its domain of discourse, not if you know what you're doing anyway.
Russell showed that the domain of logic gets tangled if you use it to think about itself. Well (with hindsight) that is no surprise at all. The expert logician recognizes the necessary boundary, and virtualizes the outer domain before it can be handled by the inner domain logic.
Russell is doing just fine, thank you. Almost the entirety of mankind's technological world is founded on the logic which you describe as "impossible".
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.