I'm getting soooo sick of this sense of self-entitlement... "give me everything for free" attitude.
If that's the attitude, then by all means be sick of it. But there are other attitudes.
My neighbors download HDTV rips of shows they're already entitled to because their Tivo doesn't do HDTV. I download the Daily Show because I'm not getting cable installed just to watch one show, and waiting for it to come out on DVD isn't working so well. As soon as Comedy Central sets up a pay-per-download scheme that's just as open and convenient, I'll happily subscribe, just like I subscribe here.
In the TRIVIA section: "Candace Gingrich, his sister, works for the Human Rights Campaign (HRC), the nation's largest gay and lesbian organization.[...]" Gee, thanks for that "trivia". The author couldn't reasonably fit that line in an article on Newt himself, so he sneaks it into the "trivia" section. Clear liberal bias here.
What exactly makes that a clear liberal bias? It's a true fact that has been widely reported, and it seems pretty interesting that siblings are on opposite sides of the political fence. The heading makes clear that it's an interesting fact, but not a significant one.
Neither was phone or power or water until the government regulated these as public utilities by recognizing that the guarantee of these services serves a greater good.
Really? Any links to the history on that? I thought the regulation was more about either a) reigning in a monopolist and squeezing goodies out of them, or b) granting monopolies to well-connected companies with lots of money. All those were thought of "natural" monopolies, which is plainly not the case with the Internet.
Similar regulation of the internet will follow that will bring internet access to similar levels of guaranteed service that other utilities offer. It is only a matter of time.
You sound suspiciously like somebody who is talking from a position of no practical experience. The regulated RBOCs are generally my last choice of a vendor when I have any choice: since they're guaranteed profits, they don't care much about good service. And that's after decades of at least occasional competition: before the breakup, these were the people who banned answering machines as dangerous.
My girlfriend does energy policy work, and so I get to hear about the functioning of the electrical regulatory process, or rather the lack of it. Of course, you might have heard of it as well: remember the California blackouts of 2001? The root cause there was idiotic regulation.
The right solution here is exactly what is playing out: people who really want reliability are multi-homed. People who don't aren't obliged to pay for something they don't want. And when vendors screw around like this they get hammered by their clients. You can bet that a lot of network admins are looking at this and seeing how Level3 prioritizes business power plays over maintaining network quality.
You can be sure that Level3 (and probably Cogent) are losing business over this one already, whereas a regulator would just be talking about considering drafting an announcement that they were examining the possibility of starting an investigation that they hoped to conclude in six to eighteen months.
expain [...] teir 1's [...] general yes [...] generaly [...] there clients [...] there peers [...] there single holmed clients [...] holming [...] bonified
Although normally it works the other way, this specacular level of English mutilation has somehow convinced me that you must really know what you're talking about. You must have extraordinary Jedi Mind Trick powers.
Sorry I'm right. You can't write software if you have no idea what its supposed to do.
This is true, but Extreme Programming doesn't require a spec to do that. Every XP coach I know generally discourages the use of written specs: there are other ways of communicating than documents.
Sorry, you're wrong. The standard XP way to organize the work is with a stack of index cards, each of which has a short phrase written on it. Those are tokens for conversations between the product manager(s) and the developers, who are all in the same room. No specification is required, and traditional spec documents are energetically discouraged.
Instead, the knowledge of what the product should be is recorded in the acceptance tests, which are written in parallel with the development. Some XPers will refer to these as "executable specifications", as that makes people more comfortable and underlines that they solve for the same problem that a lot of people try to solve with specs. But their effect is radically different than the big-spec-up-front approach that most people mean when they talk about software specifications.
Between spec-driven development and a more modern process like extreme programming, I'd take the latter. What XP and evolution have is many iterations of vigorous testing and incremental improvement. Spec-driven development lacks that.
If you spend time interviewing people in regulated fields, you'll find the paper trail isn't really about getting quality. It's about assigning blame (and therefore legal liability) when something bad happens.
Specifications are about understanding and communication, when not the whole universe is inside one person's head.
For a lot of projects, there are much more efficient means of understanding and communication. Extreme Programming, for example, puts all of the people who matter together in one room. Good writing is very hard, and good group writing is harder still. But people have a lot of natural skill in achieving understanding and communication in person.
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".
Isn't it funny the original heart pump, the one that people are born with, was put together exactly that specless way. And it lasts longer, is more efficient, and has lower failure rates, too. I wonder if we could learn something from that?
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.
I disagree utterly. I don't know from KDE/Gnome applets, but purchasing apps and games are both great examples of where you shouldn't try to pin things down. The problem is that human imagination is woefully limited.
With business software, what people say they want is heavily based on extrapolation from what they've seen. As soon as you deliver something new, their experience with that gives them new thoughts, better ideas. The optimal approach is to pin the absolute minimum, ship that, and then repeat.
Games are even more like that. The possibility space is much larger, meaning that you can only afford to implement a tiny, tiny fraction of all the cool ideas that people have. And "fun" is a much harder target to hit than "works adequately for making money". Fun also decays much more rapidly: what was fun last week is boring next week. Every game developer I've talked to spends a ton of effort tweaking things to cross the gap from "implementation of initial vision" to "rocks your world".
Advocating some sort of ad hoc "practical" computing barbarism is very short-sighted, dangerous, and regressive.
I note that 99.9999999% of the design that has taken place over the last 500 million years, give or take, was done in a fashion much more ad-hoc and "practical" than Linus is advocating. I refer, of course, to evolution.
Given that the rigorous, logical approach to engineering hasn't yet produced something as interesting as a mosquito, isn't it a little early to completely throw out the one technique proven to produce functioning complex systems, even if it does seem a bit barbarous?
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.
Software will never be like building bridges. Why? Because we relentlessly automate all of the construction process, and as much of the design process as we can get away with.
When my dad started programming, he flipped physical switches or punched physical holes for each bit. I type "ant clean deploy" and the computer flips hundreds of millions of switches for me, building, testing, and rolling out an entire app across a server farm that can serve millions.
Engineers making physical things have lots of procedures and rituals because they do similar things over and over, and because making changes is expensive. Neither has to be true in software, so it's unsurprising that software development looks nothing like traditional engineering and never will.
It must be the former. I've been doing it this way for four or so years now and it seems to be working pretty well. In July we handed a codebase off to a team in another country, and allocated time during the transition to write any documentation they wanted. They had no interest in the kind of class-internal documentation you mentioned, and I've heard no complaints or questions since that would indicate the lack.
Really, until you try TDD, you'll never get how unit tests can accomplish the things I'm talking about. Until then, I believe you're right to keep writing docs.
um. the internet bubble was the greatest bubble since the great depression
Care to quickly compare and contrast the economic effects of the Internet bubble with the Great Depression? I note a 45.6% drop in nominal GDP during the great depression versus no nonminal GDP drop at all after the Internet bubble popped.
Really, if the Internet bubble is the worst that happened in 70 years, you're making my point for me. Compared with the value we get from markets, bubbles are a small problem.
No, tests don't say how your code is supposed to work. They say the expected results for certain limited cases. This is nowhere near as clear as an actual prose description. Its also very dependant on the unit tests themselves not having bugs- and thats pretty rare. I count on a textual abstract description being accurate as far more likely than test code in my experience.
It sounds to me like you've never encountered very good unit tests. Try doing test-driven development for a couple of months and you may have a different opinion. Certainly I don't notice any of the problems you mention as being significant anymore.
Documentation tells us how code is supposed to work, both on an API level and internally. Unit tests fail this in a number of ways- they don't document internal workings, they don't document side effects at all (major problem), and they don't cover all cases (sure, you might think they do, but in reality they never quite do)
Unit tests should also tell you how code is supposed to work. Perhaps you need clearer unit tests. Think of them as executable documentation.
If the internal workings are so complicated that they really need explaining, then they also probably need testing. I break those out into another object and test those separately.
For corner cases, if you're going to take the time to write them up in documentation, it seems much better to write them up in the unit tests. Documentation requires continuous manual verification to make sure it stays in sync. Unit tests can be automatically verified. The long-term carrying cost of a unit test is much lower.
And I'm not quite sure what you mean by side effects. Shouldn't the "unit" of the unit test stand alone?
the crowds don't know shit when it comes to financial markets.
Most of the time, they do. "The Madness of Crowds" is about a relatively rare phenomenon, the speculative bubble. Most of the time markets work very well.
It's also worthn nothing that bubbles are much less spectacular than they used to be, thanks mainly to the crowd learning about bubbles and crashes. If you've read "The Madness of Crowds", you'll know that some of the early ones caused widespread financial disaster. Our most recent ones, the Internet bubble and the current real-estate bubble, are pretty minor by comparison.
If you are fortunate enough to work on a small, hand-picked team of talented programmers, I envy you. Most departments tend to spread the talent around to give the most overall benefit. In order for a team to be effective, the least talented programmer on the team needs to be able to maintain code written by the most talented, and vice-versa.
Which is part of wy I'm so big on pair programming. Few people are good enough to articulate why the length of a method is right, but if you're continously pairing with different people on your team, you continually get reminded what works well and and what's not so great. You rely less on intelligent design, and more on evolution.
I agree with you completely that programmers should write code that communicates intention well. But I disagree with this:
Plus any developer worth his salt comments when he has to work with other programmers.
I used to think so, but now I'm doing full unit testing, refactoring, and pair programming. I now think comments are the second-worst place for information about the code, (followed only by external documentation).
The best choice is to write code that's clear: short methods, clear variable names, extracting long expressions as variables to convey meaning, and extracting long blocks as clearly named methods. It helps to make good use of language constructs (e.g., private, protected, final). And of course, you should break the system into discrete objects of moderate size and packages of reasonable collections of objects.
Then the next best place for info is in the unit tests. The unit tests are a great place to explain how to use something and what the interesting edge cases are. Unlike other documentation, the computer can verify the unit tests to make sure they're always up to date.
Only if I can't find a way to express it in those do I write comments. My (and my team's) comments these days are mainly limited to a short explanation for some classes, an explation of some weirdness forced on us by an externality (e.g., "See JDK bug 510431"), or the occasional TODO comment. I doubt if our comment LOC ratio is above 1% of total code.
If I'm writing a library for public consumption, I'd use the magic documentation generation for anything that's part of the API. But for internal code? Not anymore.
RealClimate is not a credible source. It's run by an environmentalist lobbying group
The RealClimate people claim otherwise, saying that the registrant just provides them hosting. Looking at the contributor bios I don't see any reason to doubt that.
As far as I can tell the print preview suggests that once printed I can move the image around using the scrollbars or using the scroll wheel.... Only problem to solve now is how to plug my mouse into the paper!
You need a bluetooth mouse and bluetooth paper. It works fine for the regular mouse functions, but I couldn't get the scroll wheel to work.
According to this article, they currently think the main effect of global warming will be stronger hurricanes, not more hurricanes.
Of course, that's the current theory. If it turns out that we consistently get more, we'll end up with some new theories. Global warming is a big uncontrolled experiment, so it's hard to say. That's pretty sloppy science; I say we should have waited until we had two planets so we could try this side by side. And really, 20 or 30 would be better, so we could get a good statistical sample.
But there are other scenarios that I can see. [...] you and your buddy are just relaying it to the guy at the food court.
Ah, yes, that's exactly the scenario I was thinking about. I was using the term too loosely.
As I read more, though, it looks like they're only accepting the swipe for $25 or less. Given that a primary use is getting gas and given the recent price of gas, it seems like they'll have to go to $50 or so. But that still reduces the possibility for high-volume theft.
But it doesn't eliminate it. I was talking to a person who dealt with credit card fraud and he told me about people who steal gasoline for a living. One person buys $24.90 of gas over and over while their pal zaps people at the stoplight nearby. They probably wouldn't even get many chargebacks: if people are driving right by a gas station, it'd be easy for them to think they had just stopped their and forgotten.
Slashdot Mirror
I'm getting soooo sick of this sense of self-entitlement... "give me everything for free" attitude.
If that's the attitude, then by all means be sick of it. But there are other attitudes.
My neighbors download HDTV rips of shows they're already entitled to because their Tivo doesn't do HDTV. I download the Daily Show because I'm not getting cable installed just to watch one show, and waiting for it to come out on DVD isn't working so well. As soon as Comedy Central sets up a pay-per-download scheme that's just as open and convenient, I'll happily subscribe, just like I subscribe here.
In the TRIVIA section: "Candace Gingrich, his sister, works for the Human Rights Campaign (HRC), the nation's largest gay and lesbian organization.[...]" Gee, thanks for that "trivia". The author couldn't reasonably fit that line in an article on Newt himself, so he sneaks it into the "trivia" section. Clear liberal bias here.
What exactly makes that a clear liberal bias? It's a true fact that has been widely reported, and it seems pretty interesting that siblings are on opposite sides of the political fence. The heading makes clear that it's an interesting fact, but not a significant one.
Wikipedia is the opposite of knowledge: it's based on majority rule.
Really? I think it's more based on informed consensus.
Neither was phone or power or water until the government regulated these as public utilities by recognizing that the guarantee of these services serves a greater good.
Really? Any links to the history on that? I thought the regulation was more about either a) reigning in a monopolist and squeezing goodies out of them, or b) granting monopolies to well-connected companies with lots of money. All those were thought of "natural" monopolies, which is plainly not the case with the Internet.
Similar regulation of the internet will follow that will bring internet access to similar levels of guaranteed service that other utilities offer. It is only a matter of time.
You sound suspiciously like somebody who is talking from a position of no practical experience. The regulated RBOCs are generally my last choice of a vendor when I have any choice: since they're guaranteed profits, they don't care much about good service. And that's after decades of at least occasional competition: before the breakup, these were the people who banned answering machines as dangerous.
My girlfriend does energy policy work, and so I get to hear about the functioning of the electrical regulatory process, or rather the lack of it. Of course, you might have heard of it as well: remember the California blackouts of 2001? The root cause there was idiotic regulation.
The right solution here is exactly what is playing out: people who really want reliability are multi-homed. People who don't aren't obliged to pay for something they don't want. And when vendors screw around like this they get hammered by their clients. You can bet that a lot of network admins are looking at this and seeing how Level3 prioritizes business power plays over maintaining network quality.
You can be sure that Level3 (and probably Cogent) are losing business over this one already, whereas a regulator would just be talking about considering drafting an announcement that they were examining the possibility of starting an investigation that they hoped to conclude in six to eighteen months.
expain [...] teir 1's [...] general yes [...] generaly [...] there clients [...] there peers [...] there single holmed clients [...] holming [...] bonified
Although normally it works the other way, this specacular level of English mutilation has somehow convinced me that you must really know what you're talking about. You must have extraordinary Jedi Mind Trick powers.
Sorry I'm right. You can't write software if you have no idea what its supposed to do.
This is true, but Extreme Programming doesn't require a spec to do that. Every XP coach I know generally discourages the use of written specs: there are other ways of communicating than documents.
Sorry, you're wrong. The standard XP way to organize the work is with a stack of index cards, each of which has a short phrase written on it. Those are tokens for conversations between the product manager(s) and the developers, who are all in the same room. No specification is required, and traditional spec documents are energetically discouraged.
Instead, the knowledge of what the product should be is recorded in the acceptance tests, which are written in parallel with the development. Some XPers will refer to these as "executable specifications", as that makes people more comfortable and underlines that they solve for the same problem that a lot of people try to solve with specs. But their effect is radically different than the big-spec-up-front approach that most people mean when they talk about software specifications.
Between spec-driven development and a more modern process like extreme programming, I'd take the latter. What XP and evolution have is many iterations of vigorous testing and incremental improvement. Spec-driven development lacks that.
If you spend time interviewing people in regulated fields, you'll find the paper trail isn't really about getting quality. It's about assigning blame (and therefore legal liability) when something bad happens.
Specifications are about understanding and communication, when not the whole universe is inside one person's head.
For a lot of projects, there are much more efficient means of understanding and communication. Extreme Programming, for example, puts all of the people who matter together in one room. Good writing is very hard, and good group writing is harder still. But people have a lot of natural skill in achieving understanding and communication in person.
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".
Isn't it funny the original heart pump, the one that people are born with, was put together exactly that specless way. And it lasts longer, is more efficient, and has lower failure rates, too. I wonder if we could learn something from that?
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.
I disagree utterly. I don't know from KDE/Gnome applets, but purchasing apps and games are both great examples of where you shouldn't try to pin things down. The problem is that human imagination is woefully limited.
With business software, what people say they want is heavily based on extrapolation from what they've seen. As soon as you deliver something new, their experience with that gives them new thoughts, better ideas. The optimal approach is to pin the absolute minimum, ship that, and then repeat.
Games are even more like that. The possibility space is much larger, meaning that you can only afford to implement a tiny, tiny fraction of all the cool ideas that people have. And "fun" is a much harder target to hit than "works adequately for making money". Fun also decays much more rapidly: what was fun last week is boring next week. Every game developer I've talked to spends a ton of effort tweaking things to cross the gap from "implementation of initial vision" to "rocks your world".
Advocating some sort of ad hoc "practical" computing barbarism is very short-sighted, dangerous, and regressive.
I note that 99.9999999% of the design that has taken place over the last 500 million years, give or take, was done in a fashion much more ad-hoc and "practical" than Linus is advocating. I refer, of course, to evolution.
Given that the rigorous, logical approach to engineering hasn't yet produced something as interesting as a mosquito, isn't it a little early to completely throw out the one technique proven to produce functioning complex systems, even if it does seem a bit barbarous?
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.
Software will never be like building bridges. Why? Because we relentlessly automate all of the construction process, and as much of the design process as we can get away with.
When my dad started programming, he flipped physical switches or punched physical holes for each bit. I type "ant clean deploy" and the computer flips hundreds of millions of switches for me, building, testing, and rolling out an entire app across a server farm that can serve millions.
Engineers making physical things have lots of procedures and rituals because they do similar things over and over, and because making changes is expensive. Neither has to be true in software, so it's unsurprising that software development looks nothing like traditional engineering and never will.
It must be the former. I've been doing it this way for four or so years now and it seems to be working pretty well. In July we handed a codebase off to a team in another country, and allocated time during the transition to write any documentation they wanted. They had no interest in the kind of class-internal documentation you mentioned, and I've heard no complaints or questions since that would indicate the lack.
Really, until you try TDD, you'll never get how unit tests can accomplish the things I'm talking about. Until then, I believe you're right to keep writing docs.
um. the internet bubble was the greatest bubble since the great depression
Care to quickly compare and contrast the economic effects of the Internet bubble with the Great Depression? I note a 45.6% drop in nominal GDP during the great depression versus no nonminal GDP drop at all after the Internet bubble popped.
Really, if the Internet bubble is the worst that happened in 70 years, you're making my point for me. Compared with the value we get from markets, bubbles are a small problem.
No, tests don't say how your code is supposed to work. They say the expected results for certain limited cases. This is nowhere near as clear as an actual prose description. Its also very dependant on the unit tests themselves not having bugs- and thats pretty rare. I count on a textual abstract description being accurate as far more likely than test code in my experience.
It sounds to me like you've never encountered very good unit tests. Try doing test-driven development for a couple of months and you may have a different opinion. Certainly I don't notice any of the problems you mention as being significant anymore.
Documentation tells us how code is supposed to work, both on an API level and internally. Unit tests fail this in a number of ways- they don't document internal workings, they don't document side effects at all (major problem), and they don't cover all cases (sure, you might think they do, but in reality they never quite do)
Unit tests should also tell you how code is supposed to work. Perhaps you need clearer unit tests. Think of them as executable documentation.
If the internal workings are so complicated that they really need explaining, then they also probably need testing. I break those out into another object and test those separately.
For corner cases, if you're going to take the time to write them up in documentation, it seems much better to write them up in the unit tests. Documentation requires continuous manual verification to make sure it stays in sync. Unit tests can be automatically verified. The long-term carrying cost of a unit test is much lower.
And I'm not quite sure what you mean by side effects. Shouldn't the "unit" of the unit test stand alone?
the crowds don't know shit when it comes to financial markets.
Most of the time, they do. "The Madness of Crowds" is about a relatively rare phenomenon, the speculative bubble. Most of the time markets work very well.
It's also worthn nothing that bubbles are much less spectacular than they used to be, thanks mainly to the crowd learning about bubbles and crashes. If you've read "The Madness of Crowds", you'll know that some of the early ones caused widespread financial disaster. Our most recent ones, the Internet bubble and the current real-estate bubble, are pretty minor by comparison.
If you are fortunate enough to work on a small, hand-picked team of talented programmers, I envy you. Most departments tend to spread the talent around to give the most overall benefit. In order for a team to be effective, the least talented programmer on the team needs to be able to maintain code written by the most talented, and vice-versa.
Which is part of wy I'm so big on pair programming. Few people are good enough to articulate why the length of a method is right, but if you're continously pairing with different people on your team, you continually get reminded what works well and and what's not so great. You rely less on intelligent design, and more on evolution.
I agree with you completely that programmers should write code that communicates intention well. But I disagree with this:
Plus any developer worth his salt comments when he has to work with other programmers.
I used to think so, but now I'm doing full unit testing, refactoring, and pair programming. I now think comments are the second-worst place for information about the code, (followed only by external documentation).
The best choice is to write code that's clear: short methods, clear variable names, extracting long expressions as variables to convey meaning, and extracting long blocks as clearly named methods. It helps to make good use of language constructs (e.g., private, protected, final). And of course, you should break the system into discrete objects of moderate size and packages of reasonable collections of objects.
Then the next best place for info is in the unit tests. The unit tests are a great place to explain how to use something and what the interesting edge cases are. Unlike other documentation, the computer can verify the unit tests to make sure they're always up to date.
Only if I can't find a way to express it in those do I write comments. My (and my team's) comments these days are mainly limited to a short explanation for some classes, an explation of some weirdness forced on us by an externality (e.g., "See JDK bug 510431"), or the occasional TODO comment. I doubt if our comment LOC ratio is above 1% of total code.
If I'm writing a library for public consumption, I'd use the magic documentation generation for anything that's part of the API. But for internal code? Not anymore.
RealClimate is not a credible source. It's run by an environmentalist lobbying group
The RealClimate people claim otherwise, saying that the registrant just provides them hosting. Looking at the contributor bios I don't see any reason to doubt that.
As far as I can tell the print preview suggests that once printed I can move the image around using the scrollbars or using the scroll wheel.... Only problem to solve now is how to plug my mouse into the paper!
You need a bluetooth mouse and bluetooth paper. It works fine for the regular mouse functions, but I couldn't get the scroll wheel to work.
According to this article, they currently think the main effect of global warming will be stronger hurricanes, not more hurricanes.
Of course, that's the current theory. If it turns out that we consistently get more, we'll end up with some new theories. Global warming is a big uncontrolled experiment, so it's hard to say. That's pretty sloppy science; I say we should have waited until we had two planets so we could try this side by side. And really, 20 or 30 would be better, so we could get a good statistical sample.
But there are other scenarios that I can see. [...] you and your buddy are just relaying it to the guy at the food court.
Ah, yes, that's exactly the scenario I was thinking about. I was using the term too loosely.
As I read more, though, it looks like they're only accepting the swipe for $25 or less. Given that a primary use is getting gas and given the recent price of gas, it seems like they'll have to go to $50 or so. But that still reduces the possibility for high-volume theft.
But it doesn't eliminate it. I was talking to a person who dealt with credit card fraud and he told me about people who steal gasoline for a living. One person buys $24.90 of gas over and over while their pal zaps people at the stoplight nearby. They probably wouldn't even get many chargebacks: if people are driving right by a gas station, it'd be easy for them to think they had just stopped their and forgotten.