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."
something like this, this, this, this... (should i go on?)
var sig = function() { sig(); }
The summary is twisting the discussion into something very flamebait worthy, and it gives a false impression of what Linus really said.
From my impression of the discussion it isn't specs he is against, but rather following those specs without being flexible enough to take reality into account. Would you really want to fly the plane built to spec, if some of those specs turned out to not accurately reflect reality? In that case you'd change the specs, but that's not always possible.
In this specific case, the problem was someone using the abstraction layering described in the spec, while the kernel would according to the others be better off using another design. If the software behaves equivalently, it should not matter how it is designed internally.
- These characters were randomly selected.
There's a wonderful bit about specs from Jason Fried here. Pretty similar in viewpoint, I think.
Joel Spolsky certainly disagrees. And not just in theory.
Don't just read the summary at kerneltrap, but read the *entire* thread to get the full story.
Lots of the participants in the thread have a lot of history on LKML and the summary given by kerneltrap doesn't show this. Also a lot of points are made in other posts in the thread that give background to the way Linus answers.
If you don't take the time to read the entire thread, then you are not getting the full story and you are most likely to misunderstand the issue(s).
The root word of "spec" is "speculation".
No. Spec is short for specification, and has nothing to do with speculation, other than that one aims to identify something distinctly, one type of seeing, and the other entails a flight of fancy, another type of seeing.
Please don't present your own mistaken speculations as facts.
Yours Sincerely, Michael.
Really? Where did it fail?
Approximately here.
My spoon is too big.
The OSI layer was (and, for the most part, still is) a pre-code spec. Most successful specs, in particular IETF specs such as the TCP/IP suite, are *post code* specs; they were written after or concurrent with code that implements the spec (this is an IETF requirement).
Specs written before coding commit software development projects to a higher degree of complexity in a single stage of software development (specification). This additional complexity results in an increased risk of software defects in that stage and in later stages, and, independently, increased costs to implement and maintain the software.
Simplicity rules software development. Software projects succeed or fail exactly because they do or do not prioritize simplicity first. Humans are cognitively mal-adapted for comprehending non-simple systems. Exploring the spec formally (by coding it) helps humans understand complex systems. Specs are not bad, so long as that spec is code.
These are some of the tenets of Agile software development.
And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software.
I think this quote gives a better insight into what he thinks than your quote. Also you need to understand the context in which he considers the spec "useless".
- These characters were randomly selected.
I think there is some confusion between the idea of 'software specifications' and 'standard interface specifications'. One may referenct the other, but they are not the same.
Software specifications define functional, design and sometimes implimentation details, and in my experience never survive implimentation simply because the developer can never anticipate every obstacle that reality throws at it. Thus the software specification quickly is changed, after the fact, to represent what was implimented. It lags behind reality and serves only to document what *was* done, rather than driving the development.
Standard interface specifications (APIs, and other standards such as POSIX) serve as agreements between many different players about how a particular interface should work to provide interoperability between all users of the standard. If you want to foster interoperability then you follow the standards that are widely accepted. Without standard compliance Linux would not be where it is today.
I read the article and it occurs to me that the confusion between them was at the heart this very issue. This confusion is sadly furthered by the use of the term 'specification' to represent both things - which are clearly different. Implimentation of emergent technology is different than established protocol agreements. Perhaps we should couch our language to make those differences clear when we speak about it.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Okay, that may work fine for linux and commercial software, but what about more critical software fields?
Are you seriously saying that all top down specs are bad? I've worked in medical for a long time, and I really doubt that you, me, or the FDA would much appreciate a heart pump that was written from the "bottom to the top".
Specs are there for a very good reason (at least in critical cases). Also, they are absolutely critical in cases where a contract house is building a product for another company. They are the only way to in the end say, "See, here is what you asked us to build. It is perfect in every sense to your spec. Check please."
If I want a heart pump, the very first thing to do is decide what I want. That's a spec. Next comes the hazard analysis, that's a spec too. and on down, until all of the hazards are mitigated and you have a heart-pump that isn't going to do anything unexpected.
This may be an unpopular view in open-source development, but it's certainly a realistic one.
Each processor would proceed sequentially as if it had been better for them not to rise against Saul.
1) You often don't have the code (is this the "everything should be OSS" argument?)
2) If you had the source code to IE5, would you consider it a good spec?
Kjella
Live today, because you never know what tomorrow brings