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.
Detailed specs are useless. A broad spec that defines the general features, who the damn users are and what they need to achieve is far from useless. Let the intelligent software developers figure out the details, but don't let them lose sight of the general direction they should be taking.
I find this utterly insane. A big project need documentation and spec is part of that documentation in order to keep the people working on said project in touch with the image of the product the lead developer want it to become.
Without a documentation other people will just code based on lose stories the leader have told about his vision of the software. Nothing would get done as nobody would know exactly what needs to be done. And huge uncertanty would rule the porject. Also having a documentation will keep the leader itself on the correct path and not stray from it's original design. Crucial for the project to be finished
I heard he had good vision. --(o)~(o)--
something like this, this, this, this... (should i go on?)
var sig = function() { sig(); }
Who was it that said:
In theory, practice and theory are the same. In practice, they are not.
Incase you were wondering if CS was indeed a "real" science or not.
If other reasons we do lack, we swear no one will die when we attack
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.
Specs are not best for software whose features are to grow with time, and where nobody ones what people want to add more. Specs are best when you have a fixed set of requirements, which you have to meet in order to complete your work.
Still, specs may be useful for example to identify certain aspects of a Linux sub-system. But it may not be desirable to have a full spec defining all the goals of Linux, because these goals are a rapic moving target and therefore steadily changing. Of course, there are some features which are built to stay, but specifying specific features in detail while other objectives are changing or even unknown, is hard and may not give the desired results.
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
contact lenses a better choice.
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.
Bill Gates says "Beta testing is for sissies".
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
That's pretty much what it always comes back to with Linus.
If you were blocking sigs, you wouldn't have to read this.
And after three long hard years of implementing a huge amount of code as per specifications, finally wrapping things up and looking to moving on to bigger and better things... they go and change the specs! Arrraggg!!
Right as a software developer, I have both written software with specifications (that I have written or been handed) and I have written software blindly with no real path...
Quite frankly I think Linus, is not on the ball there, as both an engineer and architect, I would say that using a spec can result in very well thought out programs.
A specification does not have to reflect on reality at all! It is means to an end to explain how a program *should* work! For example, if I wanted to write an accounting package and knew nothing about accounting, I would fail miserably if I were to write it with no specifications to give me some sort of direction or understanding... The same goes for financial trading systems, if I knew nothing about it, I couldn't write it!
You need some level of documentation saying, the functionality of the program has to work in this way, i.e. we want 1 + 1 to eqaul 2, it doesn't matter how you write it in the end, as long as it still equals 2. That gives a software program some sort of direction...
A spec is only theory to give you direction... That what makes an architect different from an engineer, the architect says, "I want it to do this" its then up to the engineer (which linux is!) to implement it in a real world manner!
Usually when you write a driver for a specific piece of hardware, you take a look at the specs (of that piece of hardware and/or the stuff the hardware communicates with), and then start implementing it according to specs. Then you try to actually get it working, and the crap piece of hardware doesn't *quite* conform to the specifications. It leaves something out here, does something unexpected there, and before you know it, your driver is riddled with exceptions to make it actually *work*.
It's much better to design your driver to actually work with the hardware, and just disregard the specifications. It means your driver will actually work, instead of conforming to specs and being buggy as hell.
I guesss no one can argue Linus is a very good prorammer... YEAH RIGHT. Is Linux kernel development done at a professional level? Many people complain that Microsoft changes APIs every once in a while. How often does this happen with Linux? I guess since Linus doesn't care about specs, he can change Linux specs (APIs) as he pleases. Never mind all the stuff that gets broken. Oh yeah, and doesn't Linux aim for POSIX compliance? Isn't that a spec also? Huh? Maybe Linus should also write his own ATAPI, SCSI and USB command stuff? Take that ALSA also out. In fact, lets just forget about the whole x86 architecture.
I think there are good specs and bad specs. Good specs are the ones that are drawn up to standardize and harmonize things that are already out there. Bad specs are the ones that are written before any implementation exists. In the former case, specs are designed with hindsight, and with the knowledge of what features are desired, and how they are commonly implemented. In the latter case, specs can and will be designed without any knowledge or consideration for practical issues. Linus seems to be ranting against the bad specs, while overlooking the good ones.
Please correct me if I got my facts wrong.
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.
Theory, doesn't exist to men like Linus. Or men like Alan Cox either. The root word of "spec" is "speculation". And IMHO if you have to speculate what your needs are, then chances are you probably don't really need it.
Romana: "How did you know?" Doctor Who: "Ah, well, knowing is easy. Everyone does THAT ad nauseum. I just sort of hope"
The whole post copied verbatim from the comments in TFA.
If nothing else comments like this are ammunition for the people who dislike / want to crush Linux (and OSS in general). While I know from experience that the kernel is a quality piece of software and highly reliable if I was new to Linux and considering moving my company over to it comments like this would scare me. It's not that a spec necessarly improves the quality of the software it just improves confidence that the people writting it have a clue about what they hope to acheive.
I, too, didn't believe in writting specs when I was in college. Most of the projects I worked on were either loner affairs or the group was very small so communication was good. When I got into the commercial world though it was a very different ball game. After working on a couple of projects that failed horribly because half the team was confused about what it was supposed to be doing I realized that a spec is a very useful tool.
In my experience the better developers didn't need the spec as much as the poorer developers. The good developers almost understood without words what the other good developers would do in a given situation. The problem was no one could predict what the poorer developers would do in a given situation. This led to large chunks of the system not working / intergrating properly (I freely admit there were other serious management problems on these projecs as well) and needing huge amounts of resources to bring them back on track.
Later projects where there was a spec (even quite an informal spec) produced a better system in less time with fewer resources. I know this sounds like the same old pap that is dished up to every CS student but it really does work on non-trivial projects.
I certainly believe that the spec can be taken to far though. I have seen some projects never even get off the ground for the want of a quick hacked together bit of proof of concept code. The secret is in hitting that fine line between anarchy and unanarchy (there is no good single word antonym for anarchy so I propose unanarchy).
Perhaps the kernel only has uber leet hackers working on it. Somehow I doubt that though.
I used to have a better sig but it broke.
And here's why...
Wikipedia: "Many Linux fans tend to worship Torvalds as a kind of god. In his book "Just for Fun" he complains that he finds it annoying."If you work on programming languages, a formal semantics, whether operational, denotation or what have you are great to have -- you avoid stupid mistakes that folks notice later. E.g. the fact that statements in "C" are not expressions too.
If you work on a parser/lexer, BNF and regular expressions sure are handy -- but their advantage is that they allow you to specify, precisely and concisely, what you are doing.
With distributed systems, having a formal model of comuunications between asynchronous processes allows you to SPECIFY how they communicate and formally prove that you don't have certain killer issues: deadlock, livelock, etc.
So for some problems, specs sure are handy. Anything involving rocket ships or robots that do surgery -- I'd rather have a spec. It would be nice to have a machine-checked proof that critical systems meet the constraints too.
http://www.thebricktestament.com/the_law/when_to_
Linus Says No to 'Specs'
No 'specs'? But why? They're great machines, they would make great servers!
Please tell me is not for the RAM. Not for the RAM, please.
--
Superb hosting 4800MB Storage, 120GB bandwidth, ssh, $7.95
Picaday!!! Strange & sexy pictures (Some NSFW!).
Hosting 20G hd, 1Tb bw! ssh $7.95
I get where you're going, but isn't "spec" short for "specification." Maybe it comes from the word "special" or maybe "spectacular"?
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?
Specs are a form of communication. It's important that everyone knows what the other is doing and doing it the same way as everyone else. Appearently he doesn't like that. Linux is really starting to fall apart these days. Enough with all these crappy distro's. Free is great, but if everyone is doing thier own thing instead of making one product better, then it's pointless. http://www.theinquirer.net/?article=26642 Basically with free software, you get a mess instead of a clear focus piece of software. Why? Lack of communication and getting everyone on the same page. That's why linux will never be mainsteam. How many distro's are out there? Too many, that's what. Red Hat, SuSe, and Mandrake. Everyone else can go home. Bye! :)
Try "hierarchy".
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!"
But for any type of commercial undertaking, specs are an essential part of the development process.
Without a spec you won't know what you're being asked to build, or will find it difficult to get customer agreement that what you're delivering meets their need.
Without a spec you can't estimate, and without accurate estimates you can't insure that you're properly getting paid.
A message from our sponsor
This shouldn't really surprise anyone. His opinion is reflective his "hacker" roots, and of the care-free attitude of the Linux movement.
This is a program for hackers by a hacker
- Linus Torvalds
There's a wonderful bit about specs from Jason Fried here. Pretty similar in viewpoint, I think.
I'd say that there are good specs as well. A few examples:
POSIX standardizes programming interfaces for operating systems. It allows easy portability of applications between operating systems, and it's very successful at that. Although non-compliant operating systems (such an Windows) and non-compliant applications (many applications written for the GNU system, and any application that uses functionality not standardized by POSIX) cloud the picture somewhat, POSIX has worked wonders for application portability.
Common Lisp is a standardization of features found in Lisp systems. It mixed and matched parts from various more or less specialized Lisp systems, and built a generic programming language that is still widely regarded as the best programming language by those who know it. The fact that the language is standardized to a great extent allows code to be easily ported from one implementation to another.
R5RS is the current state of the standardization effort for the programming language Scheme. Contrary to POSIX and Common Lisp, it aims to standardize not as much as possible, but rather a small common core which can then be extended. This makes Scheme a very useful object for programming language research.
Comparing these specifications to the alternative of having no specification, I'd have to say they provide definitive advantages. Without POSIX, we'd still be stuck with operating systems having APIs different enough that it might be easier to rewrite applications for each OS, rather than maintain a single codebase with a few platfrom-specifics here and there. Language specifications like Common Lisp and R5RS have enabled a whole slew of implementations, each filling a specific niche, where other languages are often stuck with one implementation, and perhaps a few not-quite-compatible alternatives; and if you want a different niche, you'll have to use a different language.
Please correct me if I got my facts wrong.
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.
Joel Spolsky certainly disagrees. And not just in theory.
I think there is a difference between how specs work. One type tells you how things should be implemented while the other type tells you how things should work. Linus was probably referring to the type that tells you how you should implement things but nothing about how it should work IRL. The worst software i use is always done by some big megacorporation and im pretty sure there are tons of specs on that software. I think its pretty easy to mistake specs in implementations of one piece of software for specs in interacting between applications.
I also think its important to take his words for what they are, an expression of what he thinks himself, not what he thinks everybody else should think. If you dont agree, well then dont or provide a very good reason for him to change his mind.
HTTP/1.1 400
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.
NASA is extremely specification oriented in its programming tasks. The SEL maintains a website with online documentation on their process.
Specifications are useful when the "theory" is down and the execution must match. Examples are anything aerospace, underwater (read: submarines), nuclear reactors. For OS development, this would stifle it by never being able to respond to a changing environment.
Thinking Theory > Reality is what seperates programmers from computer science degrees.
The headline fooled me. At first, I though he was going to a re-hab or something
I doubt that we will ever figure out - and I suspect that even if we did figure out we couldn't do much about it
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"
Highly detailled specs: Specs
FAQ: FAQ
Support: Support
How to reply on Slashdot: Here
I don't understand why people still say that Linux is not user-friendly. Complaints
Don't you know it is now both immoral and criminal to think beyond the next quarterly report?
Is it just a discusion that is going on? If so, what is the relevance of one member of the discusion. You could also state that somebody says YES to 'Specs'.
What is more interesting is to know how much influence Linus has on Linux. If everybody is for and he is agains, does he stop things? If that is the case, then how open is Linux really?
If that is not the case and Linus is just a member in the discusion, what is the relevance if the discusion has not yet been terminated.
Don't fight for your country, if your country does not fight for you.
A spec should be used to write the acceptance tests for the application (and indeed a lot of the unit tests). Documents just sit there and don't tell you when something's wrong - repeatable tests do.
A specificiation should specify how a program behaves to the external world, not how it should be implemented.
So I think I kind of agree with Linus.
I hate specs. At the company where I work, specs have become the law for just about everything. They are usually not completely appropriate for specific examples but have to followed to every dotted i and crossed t. Specs remove all sense of control/ownership, turn a project/challenge from being fun to work on to being a slave monkey following some spec. If project fails but spec is followed, no harm. If project fails and spec is not followed, you're gone. If project is successful and spec not followed, you're not gone but in trouble. If project successful and spec followed, all good. Problem this creates is attitude that stifles innovation, adding too many downsides to taking any risk that deviates what might have worked before or what is theoretically possible.
I understand a need for specs for some general processes/information, but it can easily go overboard by insecure management.
Frankly, I'm shocked. I've been coding for more than 20 years. The idea of having specifications becomes more important by the day. Yes implementation and the specs may differ over time, that's why you need to re-visit the specs regularly. It's a waterfall model, like it's taught in schools. If implementation and specs differ, find out why, record it, update the specs. It's all due diligence and part of a rigorous and professional process. That said, many inexperienced engineers don't know how to write a good specs and it's nobody's fault: it's a learned skill. Plus it is even harder for engineers because many of them don't have good writing skills to begin with!
www.rexguo.com - Technologist + Designer
I'd hoped that Linus was refering to "SPECmarks" et al as a bad basis for writing a kernel, but specifications are way off base as being a bad idea for any area of software let alone a kernel.
Sure BAD specifications are a bad idea, but so is bad code.
Its also not true to say that a specification can't be detailed and accurate and then implemented directly, IPv4 is a pretty clear specification that I'd be worried if the kernel writers had ignored when they wrote their IP stack.
I too have seen dreadful code written directly from specifications, normally because there was no design, but I've seen much worse code written from the basis of "I think this therefore it must be right".
I'm normally a big fan of Linus, but given that many of the major areas of Linux and Open Software are written against specifications (X, Samba, IPv4, 802.11x, BIOS etc etc) its hard to see where Linus is coming from. If two organisations or technologies want to communicate they need an agreed standard and specification on the inter-operation. Any other approach is just lobbing packets and hoping for the best.
An Eye for an Eye will make the whole world blind - Gandhi
Whenever I write something to specs, I wind up rewriting it anyway when I have to interface to the software written by the people who wrote the spec. They seem to think that if they wrote it, they can break it (this is government and govt contractors here).
These days I just file the specs away, wait until they get done developing, get sample files/test server access, and write fresh code based on reality, not spec fantasy.
There's so many fallacies in Linus's assertion. He even mixes no less than four fallacies in the same sentence.
"I have _never_ seen a spec that was both big enough to be useful _and_ accurate."
First, he sets himself up for perfect justification by clarifying that he has never seen such a spec. Therefore if you argued that you've seen such a spec, he can still argue that he hasn't seen one. In the same sentence, he also puts forth the idea of a spec being both big enough to be useful and accurate. So if you showed him an accurate spec, he'd just claim it wasn't big enough to be useful.
There's also some ad hoc fallacy mixed in his argument. For example, by saying it's the single worst way to write software, if you showed him a worse method of writing software, he'd just claim "that's not really writing software", to maintain his argument.
And his entire assertion is coated in the fallacy of familiarity. He asserts that because, from his relative point of view, he has never judged a spec to be worthwhile, there must not exist any worthwhile specs.
Of course the fact that his entire argument is supported by fallacies doesn't make his conclusion wrong. But, as others have pointed out, there are plenty of examples of successful specifications which patently disprove him.
I shudder to think that Linus never wrote any specifications for Linux. Did he just open up a compiler and start typing? I can't even imagine he'd lower himself to use a compiler that was developed around (and hence tainted by) those damn language specs. How did he develop drivers to interact with the hardware without any specifications? Did he just guess at what they needed, shifting bits around one at a time until the network card responded?
Without a spec, what would a software engineer do at a company? He gets hired, sits down at a desk and and the boss says "We're writing tax management software." and the engineer asks "Any spec I can look at to get started? What component are we working on right now?" and the boss says "We don't use specs here, that's the single worst way to write software. I'm sure you'll figure out what to do."
Without specifications, the web wouldn't exist. You couldn't have web developers because you couldn't tell them where to look to learn how to build a web site. You just tell them to type and sooner or later something will happen. What if you didn't even specify what file extension to give a page? They'd just have to keep saving files guessing at extensions until they haphazardly got something to work.
[sarcasm]A world without specifications sounds like a real gem of a place to develop software in.[/sarcasm]
"Yeah guys, what's the point of specs? They're theory, not reality. So go ahead and climb in the capsule and let's see just how far you get."
It's clear he doesn't work in the consulting/contracting world either. The government agency for which I work (as a contractor) has a very real need for the software we right to meet certain specifications. And we're not even working on real-time systems. Can you imagine that attitude on the team working on fighter jet flight control software?
In talking about language specs, does anyone know where I can find a ColdFusion Markup Language (CFML) specs/syntax rule? It's seems that there are no formal definition for what characters should/shouldn't appear in the attribute part of a coldfusion tags.
All this approximations add up and so often we look at a spec only to wonder if it has anything to do with reality. In the end what gets done has more to do with the general technical culture of the implementors than the exact wording of the spec.
I think that most of the specifications for protocols are actually documenting the way the code prototypes work rather than constitute the base these prototypes.
To a certain extent, specs define the parameters around communication. That's why interoperability works: conform with the spec and you can communicate... except when you can't because the spec was built but never implemented, and the spec designers introduced bugs that they would have caught if they'd tried to implement it. Or maybe the spec designers had a specific idea of how things were going to be and didn't anticipate a particular application and it's needs.
If you accept the premise that specs enable communication, I would ask you this: where is the spec for English? And wherein does it describe things like "fo-shizzle" and "off the hizzle"? Or any other dynamic aspect of language that shows up everywhere in the world. Many people communicate without having a written spec for how that communication is going to work. More over, "fo-shizzle" (et al) is well understood by many people outside of the culture that created it despite it's never having been incorporated into an English language spec. Defining a spec for English is really pointless. The language changes and develops for the specific needs of the people using it.
It strikes me that the same is true with technology specs. If you don't define them, people will make incremental improvements to stuff without having to worry about hearing, "Hey! That's out of spec!" Put another way, specs are the antithesis of incremental change by individuals who need those changes. Specs are cathedral, not bazaar.
Are there spec success stories? Sure: IP. On the other hand how long have we been trying to get greater acceptance of IP6? And why do we want IP6 at all? Because no one is willing to incrementally change IP4.
Put another way: specs are a form of governance. They're the central group saying "thou shalt". That's fine if (and only if) that central group knows every possible implication of every decision that they make. Linus seems to be trying to avoid that. He seems to have faith that a diverse group of people will do a better job of figuring out what works best over time than he alone, or this particular set of kernel devs, could devise today.
Of course, I could be wrong.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Maybe we should draft a spec on "how to write a useful spec" and send it to Linus...
Disclosure: I'm stupid
He probably intermixed two things: Having an initial spec and adapting the spec to changes.
Changes may be triggered in the review process of a spec and while implementing a reference implementation.
If the changes in this phase are big, you're spec was lousy. Plain and simple.
Another thing: It is *hard* to produce a good, ambiguity-free spec.
And of course, once you have a reference implementation, you don't need a spec. The code is the spec.
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).
Specs are "useless" to an individual developer... but "spec" is an efficient way to communicate with your users and other developers... in case u need to.
"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
When will people realise that the code is the specification. Supporting documentation is usefull; state transition diagarams, design rationale, protocol specs etc... Detailed documentation that is generated from source is also usefull, anything else, forget it, you are wasting everyones time.
and, we all know, all browsers implement all of them correctly, right?
Take a look at your w3c specs. There's _no_ browser on eart which implements 100% of those specs. Nobody builds web pages according to w3c docs, you've to make them work in IE and firefox - none of those implements all the standards 100%.
The point of linus is mainly targetted to hardware makers. Take a look at the hell that ACPI support is, or the first motherboards who implemented IOAPIC support. Specs are _useless_ in those cases. And you can't "fix" hardware: Hardware is there, and your task is to make it work. You've two options: forget the specs, and make it _work_, or write the code according to specs.
The _real_ standars are those which are not written, ie: bugs in the POSIX implementation of some unixes that some apps rely on and that now everybody implements in other unixes because _everybody_ uses it, despite of being "wrong". Same for TCP/IP, same for "everything". I'd say that specs are OK as a reference, but if you want to write software which works in the _real_ world you must not follow them blindly. You must accept that people will not follow them and design your software according to that.
The open source BSD distributions have a reputation for being better on the back end then gnu/linux ( I honestly do not know if that is true or not ).
What do they do? Do they design what they are going to do and use specs before they do it?
Do they have a single person who calls the shots on how their kernel is done?
I probably don't know the difference between 'specs' and 'standards' but if you read Theodore's mail you would realize he's actually belittling people who religiously follow specs (Mozilla/Firefox?) and that he doesn't really have a problem if people violate specs (Internet Explorer)!
Confused?
Nandz.
Most interesting point in Linus' argument is that specs are good for _talking_. Which makes complete sense to me, as it seems that those that can't code their way out of a soggy paper bag are the strongest supporters of spec-driven development.
- It took western civilisation 2000 years to ensure popular literacy, and now we work with icon driven GUI's. Go figure.
100 page novels pretending to be specs are totally useless.
If you mod me down, I will become more powerful than you can imagine....
When you are actually designing new stuff (instead of re-typing established algorithms) you have to do a lot of thinking about how it will work. If it's big, then you will spend time and have multiple people involved. The best way to remember stuff over that time, and to allow people to understand each other is via certain documents. Code is slow to write and is easily misunderstood (as a way of communicating design intent).
Of course up-front designs are usually wrong, but they're still better than nothing (in the absense of an overwhelming precident such as UNIX). Imagine if make had been designed first, for example.
I think if you are going to write something similar to something that's been written before, then you can just jump in and start coding. But please, Linus, don't pretend your method is right for large new designs, or that you even have any knowledge of that area of software.
PS anyone noticed how in KDE the backdrop goes monochrome at the log-out window, only to flash back to colour just before shutting down? Just like Windows? Maybe sticking too closely to established designs duplicates established problems...
Attitudes like this are precisely what makes most professional organizations recoil at the thought of using open-source software.
Don't get me wrong, I am a big fan of GNU/Linux, have been using it personally and professionally since 1995. But Linus' comment comes across as naive and simplistic.
Not many practical projects can get out of the gate without having well-written specifications. Release planning, feature testing, multisite collaboration, maintainability etc are impossible without them.
Of course, it is always possible to take specs too far; they can also become powerful ammo in the day-to-day power struggles between program management/quality assurance/programmers.
However, to make a blanket statement to the effect of "specs are useless" is on the same vein as some of the other streams of thought on Slashdot like "Management is useless". It reflects a complete absense of big-picture knowledge, and anyone with real experience within an organization will discount anything else from that source immediately.
Magnus.
From the same thread again from Linus, he doesn't spare us of a weird view about what science is !
It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation.
A theory is the best explanation we have for a set of facts, a hole in it doesn't make it suddenly "wrong" if we don't have anything more accurate. (cf weird cosmologic constants and things like that). A theory beeing an approximation, it is always true.
The minds of the great and accomplished sometimes work in ways less fathomable to us mere mortals. But my take on this is "Be aware of the spec and if it matches reality, so much the better, but if it doesn't, it's time to throw away the spec." I'm considering it in the same spirit of "Just because you've seen a street map of New York, doesn't mean New York is divided into regular squares labeled 'E1', 'E2', etc. In other words, don't mistake the map for the territory." It's good advice for those wise enough to know how to take it, I think.
Get up to your elbows in code, and you'll notice the same relation between an object's spec and how it actually works that you see between a bill passed that creates a government department and what that department actually does ten years later. We *all* struggle to follow specs, standards, and protocols, but we keep running into special cases and exceptions that we have to work around.
Only an hour ago, I was grumbling over this very fact while pecking at my own box. I'm trying to write my own news-feed aggregator, and even though I'm sticking to feeds that specifically use RSS 2.0, I find the interpretation of RSS specs from one news-site to another into an actual feed are broadly applied at best and liberally amended to at worst. Once again, I have to ditch my initial "one-size-fits-all" idea (like I knew I would) and write the code to handle all the special cases and quirks (of course, this is a loose example: only three elements per list item are required, and some sixteen are "optional", with very fuzzy definitions. It's hardly expected to be carved in stone.). It's just how real life works.
Linus has always struck me as a severely practical, down-to-Earth person. His opinions can be considered as much an indictment of the spec-creation process as of specs themselves.
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.
There are different types of specs. Big, formal ones, done in a vacuum, and less rigid ones. I'm a big believer in properly defining "interfaces" between different chunks of code or modules, and effectively, that's a spec. Again, I'm sure Linus uses defined interfaces all the time.
Linus codes to specs every day; the Unix/Posix API was a useful one, certainly; he didn't just go inventing his own system calls, he used standards.
I can understand why he wouldn't want to be arbitrarily constrained in kernel development by being restricted by a spec. But perhaps if he applied a bit more of this, I wouldn't have a __foo_bar_blat when compiling and loading a module with a new kernel. (And after digging, finding out that the kernel system call is no longer present. Arrrrgh!!!) This, IMHO, is one of Linux's biggest weaknesses.
Love many, trust a few, do harm to none.
A theory in natural sciences attempts to describe an existing physical system, and a theory in synthetic sciences (like mathematics) describes a non-physical system which can be brought into existence by exact implementation of the details of its theory.
Neither of the above apply to evolving a system through iterated development or evolution, directed only by practical constraints, which is what Linus and the kernel community are doing. This makes the analogy with theories in science less than helpful.
Linus should be talking more about "fixed points" than about theories. Specs are fixed points which introduce some stability into a shifting world, and they are good both for those who want solid products and those who want to live at the bleeding edge alike. After all, when at the bleeding edge, you still want your tools to work reliably.
That said, the future of mankind (in computing) will have to replace the current ad hoc mess by hard synthetic science and engineering in due course, and therefore theory and logic will become central. However, we're not even on the first rung of the ladder in that respect.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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...
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.
Ok, I admit I did't read TFA, but if I remember correctly, we sent men on the moon with a computer that could maybe count as a P-133 nowadays, *years* ago. And today, huge companies such as MS have trouble putting code together to surf web pages! I remember using a computer years ago that when I used Notepad on it, the computer would BSOD right away.
printf($randomline(sigs.txt) \n "-- "$randomline(authors.txt));
-- myself
The reality of it is, when you're working with a massive scale project, you need a spec. Linus complains that specs are based on theory and not real world? Well, duh...the specs not supposed to hand you your code on a plate. It's supposed to describe how, in theory, this beast is supposed to work. So, you know, at any given time someone working on the project can reference it and, even if they don't know how to read code, read through the processing enough to get some idea of what's going on. What some people loose sight of is that the spec isn't only for engineerings use. Project managers, proposal writers, technical writers, etc all have to use this to perform their daily job and, not to get nasty, but engineers usually aren't the easiest to talk to get information...and it's near impossible to write a manual or do an analysis on something that somebody in the "know" thought. Engineers are busy...we're all busy...but the spec in the one unifying thing between everyone working on a project. If you take this away, we start to crumble. In my mind, this just shows the nievity of Torvald and why Linux will probably never get it's act together enough to become a dominant force in the desktop workplace.. Designed for nerds, by nerds...orchistrated by one of the biggest nerds who doesn't want to smell the reality of why the rest of the world forces "specs" and other organization tools on engineers. They're too busy to keep organized without an extra push.
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
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.
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
Humor is the right response to this, because basically, the more amorphous the problem, the more difficult the spec. There's no right answer.
o Worst case: an effort to specify a business process to be automated, with input from 25 high-powered consultants with 25 times zero years of practical experience.
o Best case: an effort to specify a coherent system with predictable input and verifiable output.
There are numerous examples of both cases cited by various respondents. Ultimately the quality of the spec, if there is a spec, comes down to a balancing act between cost and the consequences of failure. If a communications protocol is ill-defined, the result is a hung communications line. So the spec must be tight enough to allow two independent implementations to cross-communicate, or the entire effort is useless. On the other hand, if some web-based bullshit e-commerce app is specified poorly, so what, some schmuck somewhere on an odd Tuesday can't order a Swingline Stapler. It's not the end of the world.
I also claim that most creative work is spec-less by definition. You're shingling into the fog, and there isn't any chalk line to follow.
Each kind of spec has its correct use. Some (like the Pirate's Code) are more like guidelines than hard and fast rules. The rules for a Sonnet or Haiku or Limeric are quite strict, but leave a tremendous amount of latitude to produce different results. Write what you want, but if you don't follow the spec for a Sonnet, its not a Sonnet. Objective, testable specs are essential for any enterprise application to work. Very often, in such an environment, the programmers for different parts of the enterprise may never meet or even know each other's names. The spec is what binds the application together.
Maybe Linus has never seen a useful spec, it doesn't mean that they don't exist.
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.
Specs are good for propping up initial work, but they go all-to-hell quickly when projects near milestones or late completion dates. Also the mcdonalds-mentality of "hurry up with my order, I want it yesterday" that the customer always wants does not afford a lot of time to follow a regimented procedure to the tee. I've watched people (myself included) spend an assload of time writing code to follow an exact process only to constantly be late, or go crazy trying to make dates.
Programming is a creative form, no question about it. When you try and corral people's creativity into a one-size-fits-all nutshell of procedures, you are strangling possibly the largest asset they could offer you.
I encourage people to make their code readable and use comments that serve a purpose.
That's about it.
Join the Slashcott! Feb 10 thru Feb 17!
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.
Luben disagreed with linus but picked the worst possible target to back his claim. He used the scsi specs to claim that specs are necessary so that two hardware vendors can create hardware that interoperates properly. Obviously he
has never seen the exception lists for the scsi hardware within the kernel. I understand where Luben is comming from but as Linus stated it is far from reality.
Got Code?
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.
A similar paradigm is Design-Code-Test. People who Engineer software believe the design is the code. What you've pointed out is why an iterative model is much more useful. If some degree of functionality was available in the earlier stages, the problems would have been seen during the projects infancy.
We are not all-knowing, nor infallible. There are no perfect plans. Reaction is critical.
To the earlier poster who compared writing code to airplane design. basically remember that airplane dynamics and stresses and struture is dictated on by a series of "specs" that were worked out by trail and error. When they found something they do not understand you typically see the wonderful "constant" which goes like first yo multiply this form by the factor of the weight and airpraesure and then forget all that and multiply by the this and magiccaly you are now in Oz. (honestly when I took calc II years ago my professor did that I said "huh" and got back a "trust me" response. (real good for a scientific understanding-no explanation-just trust me)
In truth building software to specs is almost worse than useless. design to Interfaces(YES), but when making interop software you cannot and should not rely on how another piece does its calcs just that it does its part and spits out a response (or does its part) if it returns a structure you should use the proper accessors to read the structures data as structures change from iteration to iteration. Linus is correct in that specs are wrong in fact after a few more iterative releases they usually are out of sync and cause more problems than they could have ever fixed. If programming was like an engineering project where we had a base set to use (dynamics of metals and properties of power systems) then great specs would be good, but in truth when getting past base libs we have very little of a solid unchanging base to base a spec on. hence why computer programming is less science and more "art of"
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
The C++ specification, by contrast, is both a good spec and a bad spec.
The good part is the core of the language, which was primarily done by the committee ratifying existing practice. Read Stroustrup's Design and Evolution to see how the process worked.
The bad part is the STL spec, which was done in advance of settled, working implementations for templates. Templates in C++ are still dicey across implementations, and having a spec to aim at hasn't helped since the spec is a design document, not a codification of existing practice.
The Common Lisp spec was for the most part codification, which is why it's so good. The only place it got out ahead of community standards was CLOS, and they were smart enough to not standardize the MOP, which would have been even more premature.
Bottom line - specs as documentation of existing practice are good, specs as design documents are not good.
To a Lisp hacker, XML is S-expressions in drag.
I'm working now on some large projects and have to say - to keep specification up to date, corrected, in good shape, it requires ONE man only for that purpose. Until heaven opens and money starts pouring down on us, forget about it - software projects are usually money-stripped and they simply can't afford that. It is reason for:
* bad drivers;
* bad driver specs;
* UNwritten driver specs (forget about whole IP thingy when ask hardware guys about specs - they simply can't afford people to write it, it is very silly indeed, but mostly true);
* apps don't act like they should do;
Problem with specs is lack of reality in expectations and managers who doesn't have a clue how important is API, specs, etc. documentation;
Yes, there are well kept, in good shape specs - but usually not for hardware (what Linus actually has talked about).
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
The usefulness of specs is also LARGELY dependent on the author of the spec and their experience. Some organizations write fuzzy specs that leave a lot of wiggle room. A contractor implementing the spec then delivers a blue widget, not green because it was not clearly spelled out (not a SHALL but a SHOULD). This results in expensive engineering changes (ECs) resulting in cost overruns, budget shortfalls, and late products. Of course, if you are a Government contractor, this means you make more $$$.
Often engineers who are running projects dislike specs and believe them to be a waste of time. The development team must then attempt to work without a spec but must still work toward a goal with some internal plan and list of objectives. When the customer asks why the project is not doing A when he thought it was doing A, the development team has less ammo to defend themselves.
There are MANY examples of bad projects, cost overruns, and late products. The Government contracting area in the US has MANY examples (not just $500 toilet seats). Of course, the defence contractors get richer as they get to do it twice!
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.
Most hardware vendors say "no" to Linux.
Now before I get modded down, I be to remind whoever might read this that what I am saying is FACT. - bogaboga
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.
These examples you provided do not illustrate why specs are useless. The post illustrates why the waterfall methodology of developing software is crap.
If you had of released the software in several milestones each one of these issues would have been noticed by the customer, and you could have resolved them much cheaper. agree, no spec is 100% correct, people make mistakes, hell the market place could change. This is why the Agile methodologies preach releasing software incrementally, in small iterations.
Writing the first implementation of software from a spec is stupid, period. Hes right - its doesnt work. But once you have a reference/initial working implementation, a spec can be a useful reference for other software vendors for the purpose of ensuring interoperability. I guess my point is that I see a spec as an output, _not and input_, of the original development process.
I was crazy back when being crazy really meant something. (Charles Manson)
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!
It's been my experience that you need some sort of spec, otherwise the behavior of your program is defined by what features are easy to implement, not that which are easy to use. Anything that needs to be written for has to have a clear theoretical specification that the code adheres to rigorously, or anyone using your program will waste more time than the darn program's worth.
However, having more than just a general design when you haven't started fixing the problem and have no idea what the actual hangups you're going to run into are generally ends up with a program that isn't what you actually needed in the first place.
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.
I haven't read all the comments (who ever does?), but I wish I had mod points, because this is the most insightful comments I've seen on this post.
Do you really want software made for medical devices, airspace industry or nuclear industry, or the military, done with that philosophy ? I guess it is to bad that one of the main developers of operating systems today thinks that way.
Part of the problem lies in this overuse of C/C++ software and Algol-derived languages. Better languages are available today. Part of the solution is to move away from this dependency of C, without necessarily dropping C. An example is how OCaml was used to formaly verify the C code in the Airbus A340 fly-by-wire system: http://www.astree.ens.fr/ The Linux kernel seems to me like kid's play compared to an Airbus. In hard engineering disciplines, you are not entitled to an "opinion" like Torvald's.
Specs are for real. Lack of formal design of software has lead to the current situation of where a whole industry revolves around bugs. Increase in the use of formal methods is expected to rise, and Microsoft already has hired quite a few smart people (but they have that huge backwards-compatibility problem).
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
As a code monkey since 1981, I have yet to see a spec worth writing on any software that had not yet been written. Good specs are really just documentation of what already works. Bad specs are carefully crafted theories by brilliant people in committee. To design a great piece of software, you have to get your hands dirty.
Beer is proof that God loves us, and wants us to be happy.
Linus is in the rare position of creating that which pretty much defines everything else. He can pass on specs because (a) he understands the whole system so well that he intuitively knows what is correct, and (b) whatever he writes and chooses to release IS the defining component to which everything else must comply.
Specs are most needed when (a) the task is much less than perfectly understood by those involved, and (b) the result must comply with something else which may not be completely understood - realities which 99% of programmers must live with. Linus gets to be part of the 1%.
Can we get a "-1 Wrong" moderation option?
I was sad to see Linus choose the path of demagoguery and shout down opposing viewpoints. It's ironic that he used scientific theory as an example, because that isn't how it works at all. Authors of scientific theories welcome criticism because it allows them to work out kinks and strengthen their arguments. That's why papers are written in scientific journals for peer review. This is how software design methodology is supposed to work as well. Yes, a "spec" is an approximation of reality, but as that reality is discovered during the development process, the spec should be changed to reflect it. Unfortunately, refining the specification often means moving back deadlines, which affects promises made by business leaders. That's the reality of designing software. I think Linus is frustrated with the dysfunction often associated with the process and has identified his frustration with the process itself. It's absurd to say that software should be written by the seat of the pants. The failure of that model is what has caused software design methodologies to be created in the first place. Linus should know better than that.
"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.
I didn't read the article, and in fact I don't have a clear opinion about this thing, but one thing is for sure: in all these years, about 100% of all the engineering/kernel development arguments Linus has stated have sooner or later proven him right. So I'll just slip to the safe side, and agree with him totally. Spec no.1: Linus is always right. Wait a minute...
Strictly speaking, "computer science" is a branch of mathematics. So no, it isn't a science. Sciences are inductive and empirical, whereas mathematics is deductive and rational.
(1) Copying the engineering profession does not mean that suddenly all the problems associated with software will disappear. Engineering systems are frequently late and over-budget. I can name a few hi-profile examples: the Millennium Dome (UK), the Jubilee Underground Line extension (London), the "wobbly" bridge (London), the Sydney Opera House. The first 3 were "vanilla" projects - there was no real excuse for failure.
(2) Specs don't correspond will reality because they frequently use hand-waving to achieve functionality. That's what high level design does. If it filled in all the detail, it would not be high-level design. High-level design nearly always misses detail that emerges in implementation, because the only way to discover that detail is (1) to do the implementation, or (2) have a (non-human) ability to see the consequences of every design decision.
(3) If a design methodology is complete enough so that it does not use hand-waving, then the level of design has the same level of complexity as the implementation. Having used UML for many years, I have seen it grow so that now UML editors have so many icons, shapes, dialogs, that quite frankly I'd rather go back to code. The spec (and the language used for the spec), if it has the same level of detail, only adds complexity by hiding it and organising it in an artificial manner.
The future of software, I believe, lies in good libraries. They encompass the experience of programmers in particular domains. I use the example of ASP.NET. Applications written in ASP.NET are more robust and faster to produce that those written in ASP, and the ASP application are more stable and faster to develop than early applications written in CGI (generally). The same holds true for applications developed using different generations of Java etc.
I think the simple point is, to innovate you sometimes have to think outside the box .
Web standards for compatibility so browsers work right is needed, but standards
and specifications are not exactly the same thing, and sometimes the web may need
to break new ground that redefines old standards .
Specs are a box in a way, and all ppl come at a task from all the different angles
from their unique perspective . We all do not see "it" the same way .
The code is shared open source, and the subroutines that are most widely adapted due to their
cross platform adaptability or mutual interoperation are the ones that rise to the top .
This is practice making product, and how alot of open source mutated to become
the libraries/SDK's/scripts that are now used by the majority .
If you want ppl to come at programming issues from new, and unexpected angles, and to
boldy go where no one has gone before .
Lose the box .
Peace,
Ex-MislTech
google "32 trillion offshore needs IRS attention"
-- Robin Milner in
The LittleMLer
-- Henry Baker in
Linear Logic and Permutation Stacks--The Forth Shall Be First
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
I think what has happened here is that one guy is talking about the fence while the others are talking about the hole in the fence (figuratively speaking). In other words -- "a spec" does not mean the same thing to Linus than it does to others. That is perfectly normal -- actually it is impossible for different people to understand a concept in an absolutely same way. It is so because different words have different associations in different minds and that's a fact.
However, both sides are right! For Linus, it seems, a spec is a general outline of the program that is made before any actual coding is done and Linus obviously knows that people often think spec has to remain unchanged ever since. Linus insists that You cannot write good software if it is based ONLY on such initial theoretical assumptions and models unless the theoretist is a real genius (can foresee all possible problems). Let's assume most people are not geniuses. So, if You have a project and You have initial spec, then desperate clinging to Your initial spec during realisation phase (coding etc) will ultimately take You to a situation where You do not want to be: everything works as it should but it doesn't serve it's intended purpose or even worse -- nothing neither works nor fits together because the creator of the initial spec didn't had a clue what it was all about. So, what Linus says, is that if You think that for building good software all You need is an initial spec, then You are living in a dreamworld.
What Linus left unsaid was, that a good spec always evolves during implementation (coding etc).
I do not believe that any programmer is capable of writing software without an initial spec -- having an understanding of the goal, it's subgoals and the way leading there. It doesn't matter, if this spec is in the form of paper, file or thought, it is always there.
What the opponents of Linus are talking about is knowledge about the inner workings and standards for input and output of the program. It is self-evident that no-one can tell with 100% certainty what will software be like before goals are reached and development has been ceased. In that sence, a spec in essence is linkage of initial theoretical assumptions with the results of implementation. For Open Source Community, the availability of such knowledge is crucial. I will not talk about business collaboration, since successful businessmen have already recognised the value of intellectual capital and the need to accumulate it -- as of that business world is way ahead of OSC.
I think Linus might be worried about his own work and might be reluctant to share the real essence of his work with the public -- to keep the rabbit in the hat, so to speak. I think it's up to Linus, whether he wants to show how his mind works or not -- his contributions are big enough. In general, a person who does not create specs for his or her own work, should not waste time writing Open Source Software. It is a burden for other developers in the OSC.
Carvature is such an awesome word, I'm going to start using it as often as possible.
The carvature of that turkey was exquisite!
Grandpa's whittling expresses the subtle depression-era emotions in its fine carvature.
Our new marketing plan will be the carvature necessary to get a foothold in the widget industry.
I can generally agree with Linus that English-language specifications are hardly ever good enough to build software around. I can think of at least one notable example that is both large, useful, and accurate: The Definition of Standard ML defines the programming language SML in a way that is very accurate and thorough, to the point that the specification is almost machine-executable. (Indeed, a project is currently underway at CMU to formalize an alternate version of the definition in Twelf, and mechanically prove it correct, which would really make it machine executable.) Because of this spec, SML has several compilers that are impressively compatible, and where they differ, it's almost always clear who's right and who's wrong. (To be fair, there are some known mistakes and ambiguities in the published version, which is one of the reasons for the machine-verifiable version in development.)
The real problem is that specs are hard, I mean, way harder than writing software that more-or-less works, like linux does. If you believe "worse is better", then maybe specs aren't necessary. If you believe that it's worth the time to make sure you're really doing something right, it is possible to write specs that are accurate and useful, and that can be helpful to collect your thoughts outside the warzone of source code, and reason abstractly about the program that you intend to write.
Specs are good as a starting point (as Linus said, for the "talking" phase of development). But once you start implementing your specs, you have to denormalize them in much the same way as a database cannot practically be completely domain-key normal form -- the reason is almost always performance or ease of implementation.
Or say you were working on a healthcare enterprise application, and you thought, "Gee, wouldn't it be great if we composed our model layer to reflect HL7 specifications?" But in reality, you would end up with a hugely unoptimized and impracticle system with massive numbers of object references.
And this is one reason why I somehwhat dislike purely OO languages -- sometimes, an object isn't what you need best. But OO purists, with theory in mind, will always want to make ~everything~ an object.
random underscore blankspace at ya know hoo dot comedy.
While the totally spec-less approach is not good, neither is the over speced approach. How much of each all depends on the project at hand and also what supporting tools are available.
Many people say that engineers do everything by spec, but this is not altogether true. If you are talking about the production of the final product, then yes they do. But before that there are usually prototypes that get developed, modified and tweaked, trialled and so on, until a suitable solution is worked out.
This is where software differs. How many times have you seen a company build a software prototype, build a spec based on what was discovered and then build the final product? In nearly 100% of the cases that I have seen there is no prototype, so the final product is a prototype onto itself, but one that is worked on until it becomes a final product. While a spec can layout the essential design and even at some points make a good job of making the product work, if they aren't modified to reflect the changing realities, then their is an issue.
Remember you can have a grand design that looks good on paper, but performs terribly in reality. On the other hand you could start coding straight away and be so swamped that your realise a road-map would have been useful.
Jumpstart the tartan drive.
Frankly, I've disliked Linus(from what I know of him) for a while now. Sure I love Linux (running KDE on Gentoo) right now but I've considered him an idiot for a while now. There is this incident for example. Or his inability to understand the value of a stable API. Also I remember him dismissing switching over to C++ because they tried it once and found it too slow and hard to program in. Fine, don't use C++... but considering apparently this attempt predates the standardisation of C++ not to mention the advances of C++ I'm tempted to mark that comment as a troll. Not making the files drivers need to hook into LGPL and making binary drivers realistic is a toss-up but I think it's unreasonable. When he decided that stabilising the kernel was for distros to do... well to me it sounded like "I just wanna do the fun parts... let someone else handle that." There have been other complaints that the kernel was marked stable before it truly was and that he is unwilling to let a 'stable' kernel bew stable. Really, I wish ppl would just start using one of the *BSD kernels. I wonder how long it take for RedHat to start using the FreeBSD kernels. Considering how many kernel hackers they employ it seems like they could smoothe out the wrinkles in FreeBSD.
Your CPU is not doing anything else, at least do something.
If Linus is anti-specs then I wonder what his stance would be on Microsoft extending and/or breaking specs in their software development.
Mine is Good
Specs are crap?
;-)
I guess that's why the Freenetproject never had good specs!
And it pretty much seems a worthwile pursuit, seen the current almost-specless development of the 0.7 version.
Ok, the start was there, but it doesn't seem to get any further, even after several months.
--- "To pee or not to pee, that is the question." ---
It seems a lot of people here are basically thinking that by Linus dissing specs, he's dissing interfaces, protocols, and other standards.
I think he's mostly complaining about specs that try to enforce particular models on distinctive software components.
A spec for a particular component might give you a jumping off point, but in reality, you're going to have to tease and experiment with some code first to know exactly what you're going to do. Hasn't anyone ever heard of "iterative development"?
No one is a soothsayer, and good coding, while it should involve adhering to standards for ~communication~ between modules, should always keep machine and human efficiency first, above theoretical correctness.
random underscore blankspace at ya know hoo dot comedy.
I agree wholeheartedly, but I really don't think anyone in the thread was contesting the contrary. At worst, Linus is insane, at best, a pedant. In this case, anyway.
(didn't RTFA, but Linus made blanket statements that are quoted in the article that led me to think....)
A whole bunch of really useful software has been written that is ALL now playing catch-up to the standard. Sure, some parts are completely ignored, but generally, it is the standard for databases and the only reason they play nice at a basic level. There is no incentive for any one database company/project to adopt anyone elses protocols and standards, but if there is a univerally accepted spec that is demanded by users, they have no choice. Of course they all extend it, but they also all conform to it in varying degrees. You can create objects, insert data, and select data on any database with the exact same commands. That's pretty useful. It is due in no small part to a spec.
Having been in software development for 12 years now, I thought "he is crazy". But no, once again his comments are taken out of context. Let me summarize, for those 6 year olds: if you are a kernel developer, don't blindly follow a spec. Linus does not speak for all of software devlopment, nor all software projects. If you take his word as gospel you are a fool. I see two real problems in the industry:
1. People want to call themselves sofware "engineers" yet they don't have any inkling of what engineering is. They are programmers. Engineers don't scoff at specs and hack stuff together at the last minute. And I don't think every piece of software needs to be engineered, in fact most probably don't. But don't call yourself an engineer if what you do rejects everything engineering is about.
2. If you have seen a well written spec, you would know that they are invaluable. The problem is that you have the wrong people writing specs, or that you don't give the right people the time to write them. Get the crap out the door as fast as you can. If it is broken, we'll fix it later. Someone new on the project? Sit with them for 10 minutes and explain EVERYTHING to them. Then throw them into the fire.
And for the record, I barely remember the last time I saw a decently written spec. I'll bet it was about 8 years and 3 companies ago.
My beliefs do not require that you agree with them.
that a spec carved in stone and not thought about as each piece is wrritten and tested is useless.
Sorry Linus, I have seen specs used very well, and even be rellevant 5 years later.
If a software writer can not keep specs and documents up to date, they are a hinderence.
I have seen a lot of software that never had a spec, and all of that was terribble written, and incredibly hard to maintain.
OTOH you have more fingers.
The Kruger Dunning explains most post on
Between this and the stupid trademarking of the work Linux, I think Linus has gone off the deep end. Without specs, no one will know what to expect out of the system. If the system does Y, that's all well and good. But If the the specs that say the system should do X then you've got a major problem.
It is time to remvoe Linus from the project. He is seriously starting to hurt the open source community.
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.
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.
Lets change some words here:
Of course, it's easy to do that when you're Microsoft, and whatever you say/do is the de facto standard without the need to write a spec. Microsoft's actions are spec.
Following a spec means you could code things wrong. Who wants to be wrong?
... developing it requires little-to-no accountability, in many cases. Specs are evil, we all agree on that, but they also serve the purpose of forcing the end-user (whose wallet we're relying on in most cases) to define their needs, rightly or wrongly, so there's no misunderstanding over deliverables.
... we're not *all* stupid, we didn't all evolve towards project specifications because it was a completely flawed idea.
Characterizing specifications as globally wrong is short-sighted and immature, really, and shows an astounding lack of understanding of how real-world projects must be developed to someone's idea of what they'll pay for.
I know, I'm criticizing the holy Linus, and I'm going to get flamed in the ground, but c'mon
Most people seem to be assuming he is dismissing software design specs, which has nothing to do with his discussion.
His puported viewpoint is to be taken in the context of a hardware vendor spec on how to interface with hardware. There is a significant amount of truth in this. Hardware vendors will live by specs when they need to. I.e. they adhere to PCI specs, they adhere to drive-controller specs. They are careful about areas where they communicate on a bus or channel to arbitrary other vendor hardware.
However, the interface between the OS and the piece of equipment will almost always have poor specs. They are usually designed at the start of the design of things, and then while working the reality shifts from the spec. Unless going for some sort of standardization (i.e. IETF and such), the spec is rarely updated even in the face of significant change. At that point the reference implementation is the only thing anyone is maintaining and the only thing that particularly matters.
On the other hand, at least you know where they are coming from. Ultimately, an ideal world has a vendor releasing both specs and their reference implementation.
XML is like violence. If it doesn't solve the problem, use more.
How do you think a BIOS is typically developed:
- Reading the ACPI spec, implementing it, followed by extensive unit testing verifying that the spec was implemented correctly.
- Browsing the ACPI spec, implementing it, then trying to boot windows until it works.
If you write the Linus ACPI code according to the spec, you are betting that the first point above is reality. Not the kind of bet you would like to make.Of course, this example works as well with s/ACPI/HTML/; s/boot windows/load the page in IE/ etc. etc.
Specs are a nice thing in theory, but I have to agree with Linus' point.
If there is to be a new "thing" (ie software component, hardware componenet, interface, or whatever), then we can do one of two things:
1) one can sit down, study the problem a great deal, try to account for all edge- and corner- conditions, and attempt to write a spec which will deal with all these things.
or
2) one could start prototyping the "thing" immediately, ignore unecessary corner- and edge- conditions, bend semantic rules, etc., and get it working, and get it out the door into the {whatever-}space long before the other folks have even completed the spec. Since this would be the first "thing" that people will see, it becomes the de-facto standard (or at least the de-facto strawman) that everyone else will want to interoperate with.
This is the reality. Software moves quickly. In case number 2) the strawman will be iteratively torn apart and rebuilt until a "real" de-facto "spec" emerges. And this will be the "thing" that every one will use.
In the course of every project, it will become necessary to shoot the scientists and begin production.
We always write to specs. Usually implied. Whether it starts as just a few lines on a cocktail napkin or it's an explicit interface definition, it's just a starting point; but a project without any is guaranteed disaster. I know that requirements gathered by comittee rarely translate into live code and I personally find that the best way to gather requirements is to prototype heavily, but you have to start somewhere. Every right-thinking programmer detests documentation; unfortunately there is no substitute for the waterfall. People may think they've just written the most brilliant piece of code ever, but if it's not spec'ed and coded to that, thier grand creation becomes just another pile of steaming spaghetti code to the next poor slob that has to deal with it.
MfT
<!--
while(!am) r2();
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.
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.
Specs should, in my opinion, be a language-independent description of the task - not implementation, but structures and interfaces only. If ask you to transfer an XML document over TLS I don't care how you go about it - as long as you follow a valid XML structure and a valid TLS protocol. It gets slightly more hairy when you're dealing with hard real-time systems, but even then it should only describe fixed times or time windows. The difference is as fundamental as the difference between describing an orange and the process to grow an orange.
Live today, because you never know what tomorrow brings
Specs are rarely useful breasts up-front.
What *would* Sigmund say?
I greatly appreciate it. Spec, Analysts and Program Managers made no sense in the world of Systems Programming. I have a refrence to quote now.
Actually in the graduate math classes I've had, it was pretty much a given that the Grand Dream of Russell was shattered on the rocky shores of Godel. Seems like there was a crisis in Mathematics (due to Godel) as severe as the crisis in Physics (due to QM). It was said that before Physics could procede, a generation of Physicists would have to die out. Mathematics proved more resistant, embraced Formalism, and climbed into its navel instead. (Noteable exception: Tristan Needham's Visual Complex Analysis, also see the book's homepage.
Indeed. My reaction was: "Says the guy whose life's work is, essentially, copying other people's original work."
Are you adequate?
You know what? the specs talked about UTM coordinates, but they actually meant MGRS![...]
The specs did not say anything about the map display respecting the carvature of Earth. So we went out and implemented a flat model,[...]
Here's a thought for you. When faced with a situtation where you're not sure what the client wants, how about you ask them. Oh, wait, you're sucking on goverment tit and you couldn't care less.
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.
So there was ambiguity in the specs, they didn't state if they assumed a curved or flat model.
And instead of spending 30 seconds to email or phone your client contact, and ask what they had assumed, you just thought you'd make the decision for them?
Sure, if it's a tiny ambiguity that would take 5 minutes to reverse you just make an assumption and not pester the client every 5 mins. But for something so fundamental your crazy to just make up requirements as you go along...
... I, for one, welcome our new glasses-wearing girl overlords.
Ignore this signature. By order.
Everyone know's that moderation is done by a script. Proof:
Linux firefox good kill M$ bad OSX eat all CONSPIRACY! soviet russia assholes google google google BSDed BSD!
I don't care if it's 90,000 hectares. That lake was not my doing.
and because of IP issues. The industry is resisting standardization to some degree because companies want to make money selling library code and the like. Personally, I relate software engineering today to pre-industrial tradework like blacksmithing. Most code for every project is written from the ground up and technical tricks are jealously guarded by many software houses (IP and non-compete laws now vs. less formal methods way back when). Eventually, however, the glory days will end as the average project size simply gets too large to be managed in such a manner. Particularly when software integrity becomes more of an issue. What will happen if the law changes such that all software must provide some stability and safety guarantees? As it is, things are abysmal. I've had to replace my last two cellphones (Motorola... never buying one again) because the firmware was garbage and they crashed and freaked out constantly. And cellphones are products that are expected to Just Work. What does that say about the rest of the industry? Calling the process an art is just a cop-out as far as I'm concerned. There's a difference between striving to build a flawless product and in embracing the flaws as a consequence of the artistic process--the latter group is just excusing their lack of skill or discipline.
A good spec is one that states the goal of a certain issue and creates boundaries. However it doesn't tell you exactly the path to the goal but can give hints.
A bad spec is a spec that goes too much into detail but doesn't set the outer boundaries. (Well THIS software needs a terabyte of RAM to work, since nobody told us that we only have 32 meg to work with!)
Far too many projects have been started with bad specs. If a spec can't be summarized to an A4 page (or Letter for those who don't do ISO standards) it is time to sit down and think again. Of course it's impossible to get everything down on a single page, but you can create the basic boundaries. If the final spec is on more paper than you can comfortably put under your arm and have handy at all times - well, who do you think will read it?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The Laws of Software Process: A New Model for the Production and Management of Software
I heartedly recommend to anyone in the "engineering" argument.
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
Microsoft's idea of "software engineering"
He's not complaining about specs as a way of getting things to behave the same. He's talking about using hardware specs to base your software on. If you try to talk to your PCI hardware by following the PCI spec, chances are that it won't work, because a huge portion of PCI hardware doesn't quite work right. Someone had been saying that, in order to write a good SCSI driver, you should follow the guidelines in the SCSI spec, and Linus was saying that, if you did that, your results wouldn't work with a lot of real hardware that people use, and you won't be able to deal with these quirks, because you won't have designed your system to handle them.
It's not about the development model at all. The situation is that Linux has to work with third party devices, where the spec is like a contract that the other party hasn't signed. You can do your part to be perfectly compatible, but when the computer's BIOS tells you impossible things, you can't go yell at them, because they don't really care, and the user still wants the computer to work.
I personally wouldn't go on an airplane where the people designing it just trusted that parts perform the way the contracts specify. The most common area in engineering failures is to assume that, just because you say that something has to be done a certain way, it'll actually get done that way. I want my airplane designed such that, if a couple of the engines aren't aren't doing what the manufacturer claimed they'd do, the plane doesn't just crash. You have to expect that a certain amount of the stuff will misbehave, and the safety of your system really depends on just how much of it can misbehave before something terrible happens.
In short, if you're producing SCSI adaptors, you should understand the SCSI spec completely. But if you're writing a SCSI driver, you should have a copy of the spec, but also a big database of how particular hardware violates it, and notes on what parts are unreliable in practice, because there are certain to be a lot of these.
So your customer gave you a bad spec, you developed a product that fulfilled that spec's requirements, and it was later discovered that they gave you incorrect requirements -- and you're blaming that failure on the SPEC rather than the CUSTOMER?
The spec for sqrt(x) says that result*result=x (for complex x). Any compiler smart enough to turn this spec into an implementation of sqrt would be more complex than simply implementing sqrt itself.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Specs should, in my opinion, be a language-independent description of the task - not implementation, but structures and interfaces only.
Exactly. Further to that point, here is a discussion on that very subject, including examples of implementation and spec, and how they differ, and what the spec offers that the implementation doesn't.
Jedidiah.
Craft Beer Programming T-shirts
I'd love to see Linus get a new house built without any specs. Funny stuff!!!
Expect Freedom.
I love specs. It makes it easier to fill out my TPS report at the end of the week.
Mostly QA I think. Implementation driven by specs is fine and dandy, but the real meat of the benefit comes during testing, especially black box.
BFUD (letters intentionally perjoratively reversed) is a straw man the Agile movement beats to death, trying to justify their existence. Sure, the plans don't always work out and you have to change them in mid-stream, and you better have done some degree of planning for that. If you can't change them mid-stream, the problem was not enough planning or bad planning, not too little.
As a matter of fact, this is what good extensive up-front design process and more design along the way is most about. Having the "Big Picture" never meant having a detailed picture. It is about getting as many basics right as possible because these can be the hardest to fix later, getting it as simple, and flexible as possible, which contrary to the outspoken Agile advocacy (trying to sell their products), doesn't happen by wildly pursuing the first thing that pops into your head, and is what good software designers have been doing all along, not chasing their tails in a cycle where each generation of software doesn't learn a thing from the prior because they can't assume the responsibility that would be involved in writing it down.
If the important things are established properly, and conscientouusly revised, they can also be adjusted as necessary and the little things won't get out of control. If someone tells you up front design can't be done or is bad, it is probably just because they can't do it. Managers who think this way is called one minus management, making sure all people below you are dumber than yourself, and it doesn't produce good software, although those involved in such a process are all very proud of themselves.
Specifications aren't about theory, they're about what a system is expected to do, if it is a software specification.
How about this - Boeing engineers announce they don't need specifications, they just start building aircraft and see what happens.
"that real hackers, the ones that I have come to respect over the years, simply sat down and built the tools that they needed"
And you end up with an unmaintainable mess if it is anything more than a simple, short piece of code. Much of the time prima donna, hotshot programmers are a liability on large projects. These are the guys who claim they don't have time to comment or document their code, but also can't explain exactly what it does a couple of months later. They're useful when you need code produced in a hurry and you don't care about modifying the code again later.
But one of the most important things to do when creating one is make sure that each and every element of the specification is testable. That prevents you from wandering off into wild-eyed ivory tower land. I know, because I've been very successful at writing specications documents. On the most successful one, we had 4 bugs at the end of a three month development effort. We were on time and under budget. On the previous iteration of the system, it took three years, was over six months late, and had over 300 bugs that took three months to stomp. Granted, a good specification was not the only factor. I was working with an excellent development team and a manager who enforced good practices, such as complete code reviews for every piece of code before it was checked in.
BTW, It's not unusual for Linus to say some pretty bizarre things. Often they are taken out of context, but sometimes, like any other human, he's flat out wrong. [ waiting for the god of programming to strike me down... ]
Anyone who blindly accepts statements made by someone else should become a religious disciple, not a programmer. If you want to be a good coder, investigate and make up your own mind, don't let people tell you what to believe.
-All that is gold does not glitter - Tolkien
www.ra
> the application still has some issues regarding coordinate
> conversions.
And the application is to direct what kind of hardware?
Cruise missile, maybe?
ISSUES???
Oh, wonderful.
I remember hearing a guy in the Strategic Air Command joke that they just targeted time zones, but at least they remembered the shape of the planet made a difference.
For military purposes, assuming a flat Earth is scary.
These remarks by Linus are being taken out of context. For most programming
jobs you have a customer who specifies what they want. So a specification is part
of the deal. To the extent that the specification doesn't exist somewhere,
even if its just in the head of you and the customer, you are guaranteed to have
serious problems getting paid and ending up with a satisfied repeat customer.
I think that a lot of impressionable beginning programmers are going to take these remarks out
of context and are going to have problems on their next few interviews.
Specs are the dilbertarian weapon of choice of those who do not understand software development attempting to dictate to those who do. IE, managers. By writing overgeneralized nonrelevant specs in glossy bullet-points, it makes overseas outsourcing seem more palatable and seeks to diminish the task of complex software development into monkey points.
The crux of the problem is a lack of feedback cycle between spec development and software development. IE, often the specifications must optimally depend on knowledge of the software and tools available for completion of the project, yet that is specifically what the writer's of many specs choose to ignore. Therefore, the specs become useless.
If there was collaboration between management and engineering on the specs and time allocated to engineering to do study to develop proper specs, than it would produce more useful documents. However, that assumes management would have to respect the input of engineering, which would do away with most of the justification for creating those specs in the first place! QED.
Without a spec you won't know what you're being asked to build...
I develop software according to my customer's requirements, not specifications.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
...how specs are USED. I think his language could be clearer because it is causing a lot of responses like yours. However his opinions are quite accurate.
However, specs are not always theory, and they may be usefull, as well as docs.
Yes, many specs are absolutely essential. If developers of browsers and web content followed W3C's specifications the web would be a much better place. POSIX makes portability much more feasible. Following standards specifications is what made the internet possible.
Notice a common thread among those specs? They are all STANDARDS--one type of specification. Standards codify a common set of practices (ideally best practices but in reality there are often compromises). If there is just one kind of spec that should be honoured, it is the vendor-neutral standard. These specs are at a level quite removed from the end-user experience and are not specific to any single, specific application. Casual end-users would not directly notice whether standards are followed. Sysadmins, integrators and future developers maintaining such applications REALLY notice such things however, and eventually managers and regular end users will too--in the form of reduced maintenance costs and better reliability and interoperability.
The type of spec Linus is probably referring to are application-specific architectural and functional specifications. These sort of specs, particularly the latter type, have proven to be mostly complete wastes of time. This has a lot to do with the fact that the ways such specs are created and employed with respect to software developent are fundamentally flawed. These flaws usually have to do with doing all these specs up front then following some "waterfall" method of project management whereby you completely implement a full set of specs, periodically reviewing and doing iterations, testing then releasing.
Applying the above methods to software development, or in fact any very large engineering projects, is bullsh*t. Such methods do not scale very well. This is something I've learned in the last couple of years as I've found myself involved in projects at a higher level and have gotten a clearer view on the "big picture"--and also from seeing how my employer has had to pull some near-disasterous projects out if the fire. Successful projects have either been quite small and succeeded despite the flawed process, never followed the above model or ended up throwing out the original specs half-way through development. This has been the case whether it was a software product or a refinery.
He cited OSI model, well, but I can assure you I won't go in an airplane if it was done with Linus' practices...
The OSI model is an example of a STANDARD--a model that should be understood and respected but generally makes little sense to mimic in code and Linus says as much in his message. As for going for a ride in an airplane designed by Linus--well barring the fact that aircraft and operating systems are too different to apply the same practices I'd much rather fly the "Linux 727" than the "Microsoft DC10" any day. Furthermore, if you were to look at how aircraft are designed you'd find that they are in fact designed and built WITHOUT a "spec" of the type Linus bemoans. If a jumbo jet was designed the way a lot of people try to do software projects then hundreds of people would get together from Boeing, airlines and airports and write a huge, detailed and incomprehensible spec for a jet--for everything from the layout of the instrument cluster to the shape of the turbine blades on the engines to the size of the tires. Then the managers from Boeing, all the airlines and all the airports would "review" (or gloss-over really) the spec and sign it off and then Boeing would design the plane, following that spec for everything. Then they'd test the end product and "interate", crashing a few dozen multi-million-dollar prototypes in the process. Then the airlines would get theri first new planes and complain that it isn't qu
No wonder Linux has grown into a monster...
People people,
Linus was being asked what he thought about girls with a "secretarial look".
Yeah, yeah I'll get my coat...
Sky subscribers are morons. They pay to be advertised at !
_Jesus_ I mean _please_ _stop_ _this_ _right_ _now_ _!_ _!_
I write software to spec. In theory, that should work.
Depends on the theory, and IMHO any theory that says it SHOULD work is incorrect.
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.
My experience is that many of the gaps or flat-out errors in the spec occur, not because the author should ahve seen them but had a braino, but because the author shouldn't necessarily have seen them.
Writing a detailed spec up front and expecting to get it correct (without the growing program and its testbench in hand) is the same as writing a whole program in an editor without compiling it once and expecting the completed program to compile, run, and be error-free the first time.
These gaps in the spec become glaringly obvious when writing the code and in the iterative component testing. That's the practice.
Precicely. And that's what MY theory says should happen.
As the design procedes problems with the spec are exposed along with problems of the design. For each mismatch you examine the difficulty: Usually it's a bug in the design and you fix it. Sometimes it's a bug in the design (or its rendering into spec). Then you fix THAT (perhaps after a meeting to examine the issue and proposed solution and approve the change.)
The same is true in the design of digital hardware, such as ASICs, where design complexity often compares with an OS or application.
Hardware - both digital and otherwise - SEEMS to involve design up front. But that's not really true.
In the case of digital systems the final rendering into silicon and assemblies may be by-the-numbers. But the design of the components was an iterative process much like programming, with the design "crashing" in simulation hundreds or thousands of times before it's good enough to go to production.
In the case of other things, like aircraft and spacecraft, bridges, dams, it sometimes SEEMS like things have been reduced to design-then-build with no trial and error. But that misses a lot.
First: In many cases the function of the structures has been well defined for many product generations, with new designs often minor fit-and-cosmetic variations on something already built. Somebody designing his 30th house or 15th bridge might be able to do it with no major errors for the contractor to work around. (But somebody doing his 30th implementation of the same algorithm or the same hardware module might be able to do the same. How often does such a situation arise?)
Second: These days bridges and buildings designed by well-debugged rules don't collapse and aircraft and spacecraft normally don't come apart or fall out of the sky unless there was an exceptional event or a negelect or error in prescribed maintainence. But a lot of buildings, bridges, aircraft, and spacecraft DID do so in the past - producing data that led to design rule changes which now prevent such problems. Film is available for many of the early aircraft failures, and many of us were around to watch news footage of some of the rocket oopsies. The film of the Tacoma Narrows bridge collapse is required viewing in engineering school, and so on. But this goes back a LONG way - clear into the archaeological record. (Early Egyptian pyramids had a steep slope. There was one that collapsed partially built. Pyramids built after that were standardized at a somewhat lower slope.)
Third: When something new is attempted in these other fields it is simulated out the wazoo, just like a new chip, during the design phase. So again you get the co-evolution of design and debug.
The reason you see a qualitative difference with software is that THE PROGRAM IS THE DESIGN. When you get your "final design" done and debugged in "simulation", you're DONE.
The "spec" for software is somewhat of another animal than the "spec" for a bridge,
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
The spec for sqrt(x) says that result*result=x (for complex x).
No, it doesn't. According to your "spec", sqrt(4) = -2 is an acceptable answer. That's just not true.
Any compiler smart enough to turn this spec into an implementation of sqrt would be more complex than simply implementing sqrt itself.
You've got to be kidding.
Do you have a point?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Um, you prefer them where?
Nevermind. I don't want to know.
I think most are *entirely* missing the point about what Linus
seems to be saying.
1) The software *IS* the spec, and it will always be 100% accurate
because the spec is identical to the software.
2) Specs that attempt to simplify or translate what the software
is describing are just that, translations. Often, things get lost
or left out in translation.
"Um, you prefer them where?"
:)*
Nipples on the ass.
*It's not like there are many places one can place breasts, and they remain useful.
Have you considered that your application of Godel might be outside the domain of this discourse?
I like that show, you insensitive clod!
Good lord there is a reason engineering types could never run a succesful company. Bill Gates broke that mold and a reason why MS is the big goliath you all hate today.
Yeah, seriously. While I sympathesize with having to put up with an inaccurate spec, I think this points out some of the issues when you try to write software that you don't have any experience/domain knowledge in.
It was a military application, so the coordinate system obviously should have been in the military's version of UTM, but instead they just looked it up on the Internet (probably using Google), and went with whatever answer came up?
Again, a military application dealing with coordinates, and they ignore the little fact that the Earth is an ellipsoid. Hello, that can make a pretty big difference over just a few miles.
Bad spec or no, someone who really understood what the purpose was of what they were doing would have done things differently. Anyone who knows anything about map projections at a high school, "hey let's discover the wonders of flat map projections Mr. Wizard" would have raised a red flag. Of course, the customer may very well have wanted things done in the wrong way (for compatibility with legacy systems, for example), so this doesn't exonerate the spec by any means, but it doesn't sound like they made the best decisions in absence of just asking someone who knew better, either.
I thought not slavishly coding to spec was supposed to save the U.S. IT industry from the Indian competition? So much for that.
I _think_ I _agree_ _with_ _every_thin_g_ _he_ said_._
The specification is solid, and recognizing it will adapt to advancements in future framework design and language augmentation, GNUstep is adapting well to the changes we now call Cocoa.
I personally like Linus and I recognise him as a great Software Engineer, one of the best probably.
Taken in context what he says probably makes sense, taken out of context al-la this thread, I think it's important to note what specifications try to bring about.
Specifications exist so that Engineers, Managers/End Users, can agree in as far as possible what our project is supposed to do. They are meant to keep away creeping featurism and ad hocism.
I do agree with what I believe was Linus' core point, that following a specification when it gets in the way of obvious sense in terms of software design, is in fact senseless.
Be calm citizen... consume.
The Hermann Brain Dominance Instrument (http://www.hbdi.com/) clarifies this very well. (I'm not affiliated with HBDI in any way; I participated in a HBDI class a few years ago.) This class/test explained a great deal about these types of arguments/discussions/disagreements that have ensued over the years of my career.
I am an off-the-chart "yellow", which means I don't like specs. I find them confining and overly time consuming. I feel they slow down the development process, and get in the way of the need for a dynamic and ever changing development effort. I _need_ this flexibility to work effectively and enjoy my work. I am creative, holistic, big-picture, and a strategic thinker. But, I often start work without considering all the details and may trip across a "Whoops! Didn't think about that!".
However, my opposite, a "green", prefers specs, and can spend endless hours/weeks/months adding to the specification details. A "green" needs this structure to work effectively and enjoy their effort. A "green" can bring much needed structure and can cover all the details (avoiding the Whoops!). But, they are also the type that can end up in "analysis paralysis".
Neither method is better than the other - just different - and the effectiveness can change with the circumstances. This characterization has nothing to do with intelligence. Both methods can lead to success or failure. BUT, greater success and synergy can be achieved by a well balanced team represented by all four quadrant (yellow, green, red, blue) thinkers, who all have an appreciation for each others talents.
On a practical level then, I let the "green" people make their lists and plans (because they need to, and it helps), but I don't participate at a detail level. And conversely, they allow me to "bounce all over the place" with my ideas (because I need to, and it helps). Working together this way, we achieve synergy.
Later, at feeding time... But you'll get plenty of time to figure out the mechanism before then.
There was a rare and isolate group of people discovered some time ago where the women actually had their breasts growing on their backs, instead of their chests. Breastfeeding was very awkward but dancing was popular.
I18N == Intergalacticization
The Hermann Brain Dominance Instrument (http://www.hbdi.com/) clarifies this very well. (I'm not affiliated with HBDI in any way; I participated in a HBDI class a few years ago.) This class/test explained a great deal about these types of arguments/discussions/disagreements that have ensued over the years of my career.
I am an off-the-chart "yellow", which means I don't like specs. I find them confining and overly time consuming. I feel they slow down the development process, and get in the way of the need for a dynamic and ever changing development effort. I _need_ this flexibility to work effectively and enjoy my work. I am creative, holistic, big-picture, and a strategic thinker. But, I often start work without considering all the details and may trip across a "Whoops! Didn't think about that!".
However, my opposite, a "green", prefers specs, and can spend endless hours/weeks/months adding to the specification details. A "green" needs this structure to work effectively and enjoy their effort. A "green" can bring much needed structure and can cover all the details (avoiding the Whoops!). But, they are also the type that can end up in "analysis paralysis".
Neither method is better than the other - just different - and the effectiveness can change with the circumstances. This characterization has nothing to do with intelligence. Both methods can lead to success or failure. BUT, greater success and synergy can be achieved by a well balanced team represented by all four quadrant (yellow, green, red, blue) thinkers, who all have an appreciation for each others talents.
On a practical level then, I let the "green" people make their lists and plans (because they need to, and it helps), but I don't participate at a detail level. And conversely, they allow me to "bounce all over the place" with my ideas (because I need to, and it helps). Working together this way, we achieve synergy.
Design specs need to be taken with a grain of salt. They represent planning. Just like you need planning to deal with broken levees on Lake Ponch. you need planning to build significant systems. All plans die on contact with reality. But the planning process is essential. The hardest parts of building significant software is often in the parts that are unexpected and unplanned for. Imagine if the whole system were that way?
And the two forms merge. Just like they needed technical data on the pumps to estimate how long it would take to pump out NO, you need tech specs on file formats and application behavior to build software over a certain size.
And if you still hate specs just get contact lenses ;-)
I18N == Intergalacticization
Posters keep talking theoreticaly about how they believe things should work.
The *real* spec is "works with my drive", not the SCSI "spec".
Be honest with yourself, would you believe you were compatable if you used inspection/testing to validate compliance with a spec, or would you do testing with other implementations.
The point Linus makes is that things have to work.
If there are timing issues not mentioned in the spec that real drives require, then it won't work to point at the spec and ask all manufacturers to withdraw their drives.
Which is more important, working in the way you interpret the spec, or working with other real implementations?
If POSIX does not require something but real applications need it, Linux must provide it. If POSIX requires something but no sane application uses it, Linux can get by without it.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
In my 8 years of software programming I got to see the ugly side of 'nice specs'.. people which get fresh from college, write a spec with nice images and such.. and the end result is ugly source-code that needs to be rewritten by men like me without a spec what so ever.
;)
Note that the years of work experience in fact does not really count so much as I also see people sticking by specs after 10 years, but the kind of work they do show they didn't really got far in their career.
I agree that when you need to create a standard between different many large parties (read companies) it is a good idea to write something down. But in many cases, it simply comes down to structured programming and the best documentation about any program is the source-code itself.. it won't lie!
I also prefer to spend the most time on making the source-code work (we all have to meet deadlines) and less on documentation that gets outdated after you changed the source-code to solve some issue that the spec did not forsee.. and no, it is not a matter of making the spec better in the first place.. some situations you simply can't forsee and the timelime of several years means a higher chance of change.
Just my frustation about people who think and/or get learned on school that specs are the ideal programming model..
Let's call them unskilled programmers.