Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linus Says No to 'Specs'

ScuttleMonkey posted more than 8 years ago | from the hypothetically-speaking dept.

Linux 540

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."

cancel ×

540 comments

Sorry! There are no comments related to the filter you selected.

He would say that... (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#13702649)

...considering that LINUX SUCKS
asd
das
sd
adasadsdasdasasd

TESTIFY BROTHER! LINUX SUX AZZ (0, Flamebait)

ScuttleEnough (898616) | more than 8 years ago | (#13702831)

LOSERS FOR LINUX!

Well I say... (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#13702653)

Wow Linus kind of sounds like an ass.

Oh come on (-1)

Anonymous Coward | more than 8 years ago | (#13702700)

I know he is like _the_ nerd and all, but he does not have to wear spectacles if he doesn't want to!

I personally think it's good that he's going for that modern businessman look rather than the basement geek look, it is what he needs at this point in his career.

I agree (4, Insightful)

cheekyboy (598084) | more than 8 years ago | (#13702781)

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.

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 /* comments, so its damn easier to read and visually see, 100% ascii blows
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.

Re:I agree (1)

Itchy Rich (818896) | more than 8 years ago | (#13702823)

Its an idiot who says a spec is useless.

I agree, but would say that a group of people who say specs are useless could be devided into more categories; the idiots, the ill-informed, the misquoted...

I don't know what Linus's experience of working in software houses is like, but I find there's usually a mix of talent and experience levels, with some developers tending to need things to be designed by a more senior team member. Linux kernel development is a very different environment and I'm not qualified to comment on how the process works, but in the regular world I've seen the benefits of a good spec, and no number of celebrity kernel developers could convince me otherwise.

Linus Taken to Task (5, Insightful)

jg21 (677801) | more than 8 years ago | (#13702656)

There's a very good post later on in the kerneltrap thread:

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.

Re:Linus Taken to Task (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#13702682)

Linus is an engineer/tech. He dislikes theory work because it often gives nothing in practice.
Actually, I think he disklikes theory simply because he does not understand it! If Linux development becomes more based on theory than practical hacks, there will be no place for him on the top.

Re:Linus Taken to Task (5, Insightful)

gowen (141411) | more than 8 years ago | (#13702688)

He dislikes theory work because it often gives nothing in practice.
Indeed. And, in fact, for those specs that aren't theoretical, he's followed quite closely (albeit without calling them a spec). There's a lot of work gone in to making Linux POSIXly correct, and POSIX is a spec, even if Linus doesn't consider it one. Similarly for VESA framebuffers, or tty specs.

Basically, a spec says "X should work like this."
You follow a spec whenever it's clear that X should work like that (for whatever reasons, be they performance, clarity or interoperability). If it's not clear why the spec mandates that, it's a bad spec, but the existence of many many bad specs doesn't invalidate the concepts of specs.

By all means pick and choose the specs you decide to follow, but don't make silly generalisations.

Re:Linus Taken to Task (1, Interesting)

Anonymous Coward | more than 8 years ago | (#13702717)

"...such as Web standards, specs are necessary, and those who don't follow these specs make crap softwares/browsers!"

I don't know a single browser that fully supports most of the webs official specs. This is the point where most people would say, "except, maybe lynx." But, even there, it doesn't render to spec because of its limitations. Yeah, it's a guideline when implimenting these features, but it is rarely "written to spec."

    Man, I use firewire and USB drives at work all the time. You'd think if they have the logo on the side, they would properly support the spec. They don't. One drive may work fine in Windows, but barf on MacOS--or Linux. It is all about how the manufacturer and OS implimented the spec.

mod -1 karma whore (0)

Anonymous Coward | more than 8 years ago | (#13702731)

The whole post copied verbatim from the comments in TFA.

Re:Linus Taken to Task (5, Informative)

Rakshasa Taisab (244699) | more than 8 years ago | (#13702772)

The summary is twisting the discussion into something very flamebait worthy, and it gives a false impression of what Linus really said.

From my impression of the discussion it isn't specs he is against, but rather following those specs without being flexible enough to take reality into account. Would you really want to fly the plane built to spec, if some of those specs turned out to not accurately reflect reality? In that case you'd change the specs, but that's not always possible.

In this specific case, the problem was someone using the abstraction layering described in the spec, while the kernel would according to the others be better off using another design. If the software behaves equivalently, it should not matter how it is designed internally.

Re:Linus Taken to Task (0)

Anonymous Coward | more than 8 years ago | (#13702795)

Specs are most important for interoperability. A product which works on its own doesn't need a spec. It just needs to work. A product which is part of a bigger system needs to follow specifications. As can frequently be observed in the linux world, if there is no spec, everybody keeps changing interfaces and everybody else has to keep adapting. This becomes unmanageable quite quickly and causes stress: Information about necessary changes is lost (as there is no documentation other than the code itself, which doesn't differentiate between internal and external changes). Developers feel "out of the loop" or ignored.

Re:Linus Taken to Task (3, Insightful)

achurch (201270) | more than 8 years ago | (#13702825)

I can assure you I won't go in an airplane if it was done with Linus' practices...

Don't blame the builder if he doesn't have the tools. The real problem is that the field of software development is just too young for the sort of meaningful and useful standards and practices needed for solid engineering to have been developed. Right now, we have:

  • A design process thought out by people who have spent way too long thinking about design theory (in theory, theory and practice are the same--in practice, they're not)
  • A bunch of programming languages, most of which were created by looking at earlier ones and saying "hey, I can tweak this and call it a new language!"
  • A testing methodology that says "throw everything in the book at it, and hope your book isn't missing any pages"

That's not exactly a recipe for success. Granted, it is possible to make things work right for a single project if you throw enough effort into it (e.g. the Space Shuttle software), but the vast majority of developers don't have that kind of effort available to throw around, and we're still a good number of years (decades?) away from figuring out what everything has in common and how to make it work cleanly. We're making progress, certainly--concepts like encapsulation spring to mind--but there's still a long way to go before you can talk about "software engineering" the same way you do, say, "civil engineering".

Re:Linus Taken to Task (1)

EntropyEngine (890880) | more than 8 years ago | (#13702847)

He clearly makes a sound argument, so I'm not sure why anyone would be confused by what he said, which is largely very unambiguous.

What I will say is, his opinions / observations don't always hold true.

Sure any qualified specification is a conglomeration of best practices and the knowledge of how to do something the right way through hard-learned experience?

I certainly don't go and throw an idea into any of my specifications without being sure of its validity beforehand...

Re:Linus Taken to Task (5, Insightful)

dramenbejs (817956) | more than 8 years ago | (#13702850)

You are saying it here: However, in a commercial environment, defining the spec is really writing a contract, which protects both the customer and the editor. Spec is not usable for coding, but for employing. You come inevitably to three possibilities:
  1. Your project is trivial and spec may be achievable.
  2. Your project is not trivial and spec is copied from some existing product
  3. You have written the spec after making the program.
There is no way around this! Or you can predict ALL of reality? I doubt...

Detailed specs... (3, Interesting)

jemnery (562697) | more than 8 years ago | (#13702657)

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.

Re:Detailed specs... (1)

lisaparratt (752068) | more than 8 years ago | (#13702720)

Let the intelligent software developers figure out the details.

You're obviously dealing with a different breed of software developers than I'm used to.

Re:Detailed specs... (1)

stunt_penguin (906223) | more than 8 years ago | (#13702732)

I agree- a detailed spec. at the start of a project will almost immediately be made redundant by a small problem or change that is required for technical, legal or usability reasons. It is much better to create a general spec, then gradually refine any specifiactions as the project takes shape so that management stay informed and worker bees like me know what direction they're working in.

A plan is a list of things that will never happen.

Re:Detailed specs... (0)

Anonymous Coward | more than 8 years ago | (#13702761)

All well and good for server applications, but what about something with a user interface? You want to leave that up to a developer? Not to mention having him just figure it out as he goes?

Re:Detailed specs... (1)

aralin (107264) | more than 8 years ago | (#13702801)

Quite the opposite. General specs like this are completely useless. Specification is at its best when it describes some fixed and strict process or protocol to be exactly followed. Like the HTML spec. Or the POSIX spec. Specification that sort of list all the features some program is supposed to have is more than useless for its high affinity to change. Then you have the problem with de-normalizing your source of truth with code and spec getting out of sync and you being left in chaos.

What? (0)

lordmetroid (708723) | more than 8 years ago | (#13702661)

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

Re:What? (5, Insightful)

Scarblac (122480) | more than 8 years ago | (#13702692)

Also having a documentation will keep the leader itself on the correct path and not stray from it's original design.

It is extremely rare that the original design is the correct path.

Re:What? (1)

DanteLysin (829006) | more than 8 years ago | (#13702778)

No one said that the original spec cannot be modified as project time goes on. The ability to identify change and modify the detailed spec, meeting the original goals, makes a good project planner.

Re:What? (0)

Anonymous Coward | more than 8 years ago | (#13702815)

If we're revising the spec on a regular basis it sure as hell better not be a formal spec with some approval process, unless you want to spend days dead in the water waiting for the "correct path" to come down from on high.

Re:What? (0)

gol (635335) | more than 8 years ago | (#13702703)

ok... well
it seems to me linus is stuck on the problem of conflict between spec and reality. In this situation it's very simple - the spec is wrong. The problem with many bad SEs is that they don't accept that Specs and other documents need to evolve during the project as everyone's understanding of the problem grows as well.
David Parnas' work on the US Navy's A7 aircraft is a brilliant example of how a spec worked. The Spec was so good that when the rights to reproduce and own the plane was sold to the US Army the Spec was used as the contract. It was a thorough description of what the plane did.

Re:What? (0)

Anonymous Coward | more than 8 years ago | (#13702715)

I find this utterly insane. A big project needs documentation and a spec is part of that documentation in order to keep the people working on said project in touch with the image of the product that the lead developer wants it to become.

Without (a) documentation other people will just code based on loose stories the leader has (ve) told about his vision of the software. Nothing would get done as nobody would know exactly what needs to be done. And huge uncertainty would rule the project(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


Bollocks, this sort of documentation requires resources the Linux project neither has nor needs.

Re:What? (1)

rtb61 (674572) | more than 8 years ago | (#13702814)

It will depend upon peoples definition of a specification. In terms of software the initial definition is a set goals to be achieved not the method by which it is achieved, as the method is the code itself. With each software package being a prototype rather than a production model a specification can not be achieved in reality as the specification relates to constructing of a production model (and it's variants) based upon the lessons learned from producing a prototype. So it would depend whether you consider a software specification to be a set of goals as well as a component breakdown (to distribute the workload) rather than a detailed method of producing the code (which of course can't be achieved until the code is written and tested).

Linus Says No to 'Specs' (5, Funny)

Anonymous Coward | more than 8 years ago | (#13702664)

I heard he had good vision. --(o)~(o)--

Re: Linus Says No to 'Specs' (0)

Anonymous Coward | more than 8 years ago | (#13702811)

You forgot the masking tape in the middle! C'mon, we're self-respecting geeks here.

you mean... (2, Informative)

Rui Lopes (599077) | more than 8 years ago | (#13702665)

something like this [w3.org] , this [w3.org] , this [w3.org] , this [rfc-editor.org] ... (should i go on?)

Theory (5, Interesting)

StonePiano (871363) | more than 8 years ago | (#13702670)

Who was it that said:

In theory, practice and theory are the same. In practice, they are not.

Re:Theory (0)

Anonymous Coward | more than 8 years ago | (#13702707)

If the theory does not match the practice, the theory is incomplete. In other words, fix the theory. Don't make vague and stupid generalizations against it. Those generalizations are nothing more than rationalizations for the sake of the idiot makeing them.

Re:Theory (5, Insightful)

StonePiano (871363) | more than 8 years ago | (#13702841)

If the theory does not match the practice, the theory is incomplete. In other words, fix the theory. Don't make vague and stupid generalizations against it. Those generalizations are nothing more than rationalizations for the sake of the idiot makeing them.

Yes, you are right... in theory.

I write software to spec. In theory, that should work. In practice it often does. But often there are gaps in the specification that the guy spec'ing should have seen, but didn't. Perhaps, his kids woke him up 20 times last night, perhaps someone made a bad pot of coffee.

These gaps in the spec become glaringly obvious when writing the code and in the iterative component testing. That's the practice.

Now, if you invest 5 times the effort in the specification, you can probably get it all. But in practice, it's often better to prepare a rough, incomplete functional specification. Make a special effort to specify the interface between interacting parts of the system, especially if they are developed by differnt teams. Then allow the developers more scope to communicate and modify this in the development process.

I'm not saying this is a good idea for building spacecraft. But it makes sense for commercial software development.

Re:Theory (0)

Anonymous Coward | more than 8 years ago | (#13702845)

Yogi Berra

Linus: It's like real science. (1, Funny)

loqi (754476) | more than 8 years ago | (#13702673)

Incase you were wondering if CS was indeed a "real" science or not.

Amen (5, Funny)

Anonymous Coward | more than 8 years ago | (#13702674)

Linus has spoken.

No to Specs... (5, Funny)

Anonymous Coward | more than 8 years ago | (#13702677)

..big _YES_ to underscores.

I don't get it - of course you need specs (4, Insightful)

Sanity (1431) | more than 8 years ago | (#13702680)

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.

You read the code (2, Interesting)

Rogerborg (306625) | more than 8 years ago | (#13702701)

That's pretty much what it always comes back to with Linus.

Re:I don't get it - of course you need specs (0)

Anonymous Coward | more than 8 years ago | (#13702722)

I would expect him to appreciate communication after doing so much team work via the net. He was probably misunderstood there. He talks about contamination of specs while others defend the concept of spec.

Re:I don't get it - of course you need specs (3, Insightful)

gowen (141411) | more than 8 years ago | (#13702744)

He talks about contamination of specs while others defend the concept of spec.
Yes, but "Linus Says No To Bad Specs" just doesn't generate the same level of ad revenue^H^H^H^H^H^H^H^H^H informed debate on slashdot.

specs are useful, but depends on objective (2, Interesting)

dorkygeek (898295) | more than 8 years ago | (#13702681)

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.

Re:specs are useful, but depends on objective (1)

Decaff (42676) | more than 8 years ago | (#13702723)

Specs are not best for software whose features are to grow with time

Why not? Specs can change and grow with time as well.

Re:specs are useful, but depends on objective (0)

Anonymous Coward | more than 8 years ago | (#13702735)

If you rewrite the spec as you go along Id call it documentation, not a spec ;)

Re:specs are useful, but depends on objective (1)

Oligonicella (659917) | more than 8 years ago | (#13702840)

You don't rewrite the spec to match the coding. You rewrite (portions of) the spec if you find a logical error.

Re:specs are useful, but depends on objective (1)

dorkygeek (898295) | more than 8 years ago | (#13702740)

Why not? Specs can change and grow with time as well.
Indeed, but in the Linux development process, I guess that a spec of a new feature is written, then implemented, and if problems occure, the spec is changed again. If you only write a spec, then implement, then change the spec and reimplement again in short cycles, then the spec can serve nothing more as a description one abstraction level higher than the actual code itself, instead of being a planning device with long-term stability.

Re:specs are useful, but depends on objective (1)

Skye16 (685048) | more than 8 years ago | (#13702741)

Mmmm, but specs can change. Obviously you don't want to change them daily (what's the point???), but they still have a degree of flexibility. Also, if you create specs for all the subsystems, then combine them all together, what does that give you? A spec for almost the entire system (sans the way it's all linked together and interoperates, and it really does make a good deal of sense to create a spec for THAT, too).

If there comes a point where the particular subsystem spec or overarching "wrapper" spec is a bit "wonky", then get together with a few more engineers, figure out how it "should" be done, rewrite the spec, and implement the desired change.

I've only been out of college and developing for a year and a half, but this method seems to work best for us. Of course, when we do change the specification/requirements, we have to get the client to sign off on them, but as we always have justification, this is an extremely minor problem.

Who knows, though. Maybe I'm missing something.

Re:specs are useful, but depends on objective (1)

dorkygeek (898295) | more than 8 years ago | (#13702760)

Well, don't get me wrong. I myself wouldn't want to develop without having a thorough spec (written by either the requirements analysts or myself), but with Linux where there is quite chaotic development in terms that people are writing parts hidden away in their closet and then suddenly want to have it merged into mainline, where noone expected such a thing, it may not be desirable to have an overall spec.

Specs are for geeks (2, Funny)

sore loser (778892) | more than 8 years ago | (#13702683)

contact lenses a better choice.

Missing the point. (5, Insightful)

Anonymous Coward | more than 8 years ago | (#13702687)

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.

In other news (5, Funny)

$RANDOMLUSER (804576) | more than 8 years ago | (#13702693)

Bill Gates says "Beta testing is for sissies".

Re:In other news (1)

Tx (96709) | more than 8 years ago | (#13702711)

You misspelled "paying customers".

Re:In other news (1)

houghi (78078) | more than 8 years ago | (#13702806)

Bil Gates says: "Paying customers is for sissies."

Re:In other news (0)

Anonymous Coward | more than 8 years ago | (#13702742)

In other news:

Steve jobs says "I'm a sissy".

Re:In other news (1)

xtracto (837672) | more than 8 years ago | (#13702835)

Tell that that to Google...

Spec Change! (2, Insightful)

linebackn (131821) | more than 8 years ago | (#13702705)

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!!

specifications are good for real world stuff (1)

the_thunderbird (682833) | more than 8 years ago | (#13702706)

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!

Specs are indeed useless (1)

TallGuy (12087) | more than 8 years ago | (#13702712)

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.

Re:Specs are indeed useless (1)

Tx (96709) | more than 8 years ago | (#13702739)

"Disregard the specifications" - so are you saying that a nearly accurate hardware specification isn't a good starting point? You don't disregard the specs, you just don't assume they're perfect. Use 'em, don't trust 'em.

Re:Specs are indeed useless (1)

RAMMS+EIN (578166) | more than 8 years ago | (#13702817)

``It's much better to design your driver to actually work with the hardware, and just disregard the specifications.''

And how do you propose to write a driver that works with the hardware, without looking at the spec of how that hardware works?

The right way to proceed here is to write the driver according to the spec, and when you find out something in the hardware doesn't work as detailed in the spec, notify the authors of the spec and the hardware, so that the mismatch can be resolved (which will usually boil down to changing the spec, as changing hardware is expensive).

Problem that is Linus... (1)

msormune (808119) | more than 8 years ago | (#13702714)

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.

Good specs and bad specs (1)

RAMMS+EIN (578166) | more than 8 years ago | (#13702719)

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.

Re:Good specs and bad specs (1)

Fallus Shempus (793462) | more than 8 years ago | (#13702800)

Meanwhile back in reality...
I have to write specs to define work that is required all the time,
yes there are times when something is overlooked so the spec changes during coding.
Sometimes the problem is more with the coder not having the intelligence to
figure out when something just won't work.
And Sepccign is a pain in the arse, but you quickliy learn to do it right
You're a big man, but you're in bad shape. With me it's a full time job. Now behave yourself.

What an idiot! (5, Funny)

kevin lyda (4803) | more than 8 years ago | (#13702721)

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.

Re:What an idiot! (1)

LiquidCoooled (634315) | more than 8 years ago | (#13702762)

Make sre your spec includes an appendix listing every possible permutation of the regexp including detailed hand crafted examples of it in operation.

A screenshots section would be handy as well for the slashdot crowd.

Re:What an idiot! (3, Funny)

CortoMaltese (828267) | more than 8 years ago | (#13702791)

Who is this Linus guy anyway?

You remind me of Oolon Colluphid's trilogy of philosophical blockbusters:

  • Where Linus Went Wrong
  • Some More of Linus' Greatest Mistakes
  • Who is this Linus Person Anyway?

specs and designs (4, Interesting)

idlake (850372) | more than 8 years ago | (#13702724)

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.

Sounds fair enough to me (4, Interesting)

Rogerborg (306625) | more than 8 years ago | (#13702725)

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.

Remember Linus is a hands-on practical kind of man (1, Insightful)

xeniten (550128) | more than 8 years ago | (#13702730)

A spec whether specific or general, large or small is in some way rooted in theory...Duh. I know. But it's not as obvious as that or this thread wouldn't exist. It seems to me that real hackers, the ones that I have come to respect over the years, simply sat down and built the tools that they needed, at the moment, based on their practical real world at the moment wants and needs. AKA "they scratched their personal itch." They simply had no time for theory.


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.

   

Re:Remember Linus is a hands-on practical kind of (0)

Anonymous Coward | more than 8 years ago | (#13702753)

I get where you're going, but isn't "spec" short for "specification." Maybe it comes from the word "special" or maybe "spectacular"?

Re:Remember Linus is a hands-on practical kind of (0)

Anonymous Coward | more than 8 years ago | (#13702782)

The root word of "spec" is "speculation".
er, isn't 'spec' from 'specification'? just a thought...

Ammo for the enemy (2, Insightful)

squoozer (730327) | more than 8 years ago | (#13702736)

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.

Antonym (0)

Anonymous Coward | more than 8 years ago | (#13702767)

Try "hierarchy".

Re:Ammo for the enemy (1)

Durzel (137902) | more than 8 years ago | (#13702771)

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.

Hit the nail on the head.

Even if a technical specification doesn't totally reflect the final product, it inspires confidence that the development team behind it followed some sort of structure as well as hopefully demonstrating that the team has a full understanding of how the system works (for post-live support, etc).

Linus Wants You To Hate Him (1)

Dante Shamest (813622) | more than 8 years ago | (#13702737)

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."

Linux doesn't work on certian problems (1)

putko (753330) | more than 8 years ago | (#13702743)

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.

Linus Says No to 'Specs' (1)

Saiyine (689367) | more than 8 years ago | (#13702748)


Linus Says No to 'Specs'

No 'specs'? But why? They're great machines [wikipedia.org] , they would make great servers!

Please tell me is not for the RAM. Not for the RAM, please.


--
Superb hosting [dreamhost.com] 4800MB Storage, 120GB bandwidth, ssh, $7.95
Picaday!!! [picaday.host.sk] Strange & sexy pictures (Some NSFW!).

Feature creep (3, Insightful)

Durzel (137902) | more than 8 years ago | (#13702759)

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?

Linus doesn't like to talk to people (0)

NXprime (573188) | more than 8 years ago | (#13702763)

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 [theinquirer.net] 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! :)

There are specs, and there are specs. (5, Insightful)

satch89450 (186046) | more than 8 years ago | (#13702768)

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!"

Fine for non-commerical projects (2, Insightful)

The Mutant (167716) | more than 8 years ago | (#13702769)

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.

Not surprising (1)

ilitirit (873234) | more than 8 years ago | (#13702770)

This shouldn't really surprise anyone. His opinion is reflective his "hacker" roots, and of the care-free [uiuc.edu] attitude of the Linux movement.

This is a program for hackers by a hacker
- Linus Torvalds

POSIX, Common Lisp, R5RS (2, Insightful)

RAMMS+EIN (578166) | more than 8 years ago | (#13702775)

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.

Joel Spolsky (3, Informative)

diepan (258887) | more than 8 years ago | (#13702783)

Joel Spolsky certainly disagrees [joelonsoftware.com] . And not just in theory [joelonsoftware.com] .

Specs or Specs? (1)

miffo.swe (547642) | more than 8 years ago | (#13702785)

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.

If they're good enough for the Space Shuttle... (5, Interesting)

Stone Rhino (532581) | more than 8 years ago | (#13702789)

Reading this article brought to mind another one I saw mentioned on slashdot a while back, about the team that writes the code for the space shuttle's computers. They write what's considered to be the finest code in the world, which essential for running a rocket ship weighing several million pounds and moving at several thousand miles per hour. How do they do it? Specs, lots of specs. According to the article [fastcompany.com] ...

At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.


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.

NASA SEL (1)

weilawei (897823) | more than 8 years ago | (#13702793)

NASA is extremely specification oriented in its programming tasks. The SEL maintains a website [nasa.gov] 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.

Well thats how it is (0)

Anonymous Coward | more than 8 years ago | (#13702797)

Thinking Theory > Reality is what seperates programmers from computer science degrees.

Linus Says No to 'Specs' (1)

Muhammar (659468) | more than 8 years ago | (#13702798)

The headline fooled me. At first, I though he was going to a re-hab or something

Proof of the pudding and all that (3, Insightful)

nagora (177841) | more than 8 years ago | (#13702805)

Given how many commercial, fully spec'ed projects fail or are not even delivered, or are delivered late and over budget, is there really that much evidence that anyone knows how to write complex software at all?

Maybe "what works" is the best approach, especially for an open-ended project like Linux.

TWW

We don't need specs (1)

BlueTrin (683373) | more than 8 years ago | (#13702818)

Highly detailled specs: Specs [kernel.org]

FAQ: FAQ [google.com]

Support: Support [linux.org]

How to reply on Slashdot: Here [google.com]

I don't understand why people still say that Linux is not user-friendly. Complaints [google.com]

What does this mean for Linux? (1)

houghi (78078) | more than 8 years ago | (#13702819)

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.

A Spec Should Define the Test (2, Insightful)

the_lesser_gatsby (449262) | more than 8 years ago | (#13702824)

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.

specs (0)

Anonymous Coward | more than 8 years ago | (#13702832)

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.

I'm shocked (1)

rexguo (555504) | more than 8 years ago | (#13702833)

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!

Why kernels always need specifications... (2, Interesting)

MosesJones (55544) | more than 8 years ago | (#13702843)


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.

Matches my experience (0)

Anonymous Coward | more than 8 years ago | (#13702846)

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.

Too many fallacies (1)

Jekler (626699) | more than 8 years ago | (#13702852)

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]
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>