Actually, Ford isn't paying royalties on anything. Ford and Toyota have cross-licensing agreements for various hybrid components and other automotive technologies. Ford developed their hybrid drive independently of Toyota's; the thing is the engineering problem only lends itself to so many economical solutions. (Notably, Ford's design is based more on the Volvo hybrid, but both the Volvo/Ford design and Toyota's use a modified Ravigneaux gearset - that's where the IP conflict arises).
Mostly these technologies have to do with the transmission and, I believe, some of the control mechanisms and algorithms. But, despite what you have read in most media outlets, Ford is not buying parts or designs from Toyota (at this time).
Now this is what the issue is really about - I'm surprised someone else recognised the difference between 'private' and 'sensitive'.
Of course, there are still complexities with this - when does public information become sensitive? How do you deal with that aspect of things?
My personal opinion is that simpler is better - the less "information" is required to do something, and the less somethings that are necessary to do, the less risk there is of something being sensitive. For instance, if the only way to get your money was from a bank, in person, where you open your account with someone and they take a picture of you and have it in the back so when the employees leave, and only you can change that picture in person, any other information is not sensitive (of course, a theif who really wanted could impersonate you, but that's a lot more difficult than most theives would consider attempting). It's only when you want to do things "remotely" (i.e., "with convenience") that sensitivity becomes an issue. Think about computers - security is much simpler if you actually have to be at a computer terminal to get information than over a network, because the best a network can do is check to see if you have the right passwords / encryption / or whatever - and those things do not guarantee that you are "you".
This is all about another tradeoff - convenience versus security. I don't think it's possible to have both at high levels. As far as I can tell, at any rate;)
The privacy argument is really pretty simple:
If somebody were to follow you around all day, everyday... from your house to your work to the convienience store, and anywhere else, would you get creeped out? Or more accurately, if you knew somebody was doing this but couldn't see them (they sent you summaries of what you did that day or something) would you like that? Would you want to stop them from doing this by invoking some anti-stalking law?
Interesting example, and here's the dilemma: while I agree that such things tend to "creep people out", what is the fundamental thing that an "anti-stalking law" is addressing? Is it the "peace of mind" of citizens? If so, there has to be something in the law that clearly, objectively defines what "peace of mind" is. You can't claim that people have the right to have their "happiness" protected, because some people have recognized "conditions" such that violence makes them happy. (Yes, I'm using reductio ad absurdum here.) This is not to say that I agree that people should be allowed to stalk or anything; I'm just saying it's not that easy to write laws that prevent this type of thing. However, I'm not sure how Real ID is the same as being stalked; it just makes it easier for people who want your information to get it. People who really want your information know where to look, and it's not in your shredded paper. Public records are, well, public.
If you would not like somebody following you everywhere in this way then you are either against the Real ID or feigning ignorance.
But fundamentally the issue is whether you think obeying laws should be a person's responsibility or something enforced mechanically, because ultimately Real ID is about the latter. Seriously, how many war funding bills do you think it will take before your car will refuse to start without reading your id card first and checking wirelessly against a national "ok-to-drive" list? Or for that matter before the voting booth will require a machine-readable ID before allowing you to place your 'anonymous' vote? Do you want to be mechanically excluded from virtually everything with flip of a bit because some CITI thinks your daily patterns changed too much and requires an explation first, or do you want humans to always be in the loop?
I agree that mechanical enforcement of identification is inferior to "personal" enforcement. This is mostly because "mechanical" means have to follow rules, and are therefore only as good (or bad) as those rules. However, I think the reason people are relying on these mechanical means is a complicated issue that includes things like liability, "personal rights," and things that many people advocate: machines don't care about your ethnicity, they just care about some number in your database. They don't even care what the rule about the number is, they just coldly and consistently apply those rules to those numbers.
The interesting thing is that in these "doomsday" scenarios about restricting rights and requiring cars that require identification and all that is that, at some point, the populace will start to vote down things, and call for reform. Assuming that the governmental processes that set up the nation are still followed, things will be corrected. The only reason, in the US at least, that "rights" are removed is because the public doesn't care enough about them to make their voice heard in voting. If people want to make cars that don't have these gadgets and the law requires it, the populace needs to change the laws. It may not be fast-food quick or easy to do so, but it can be done.
The more you actually think about the ramifications the more you should be against this id.
I'm more against the philosophies of life that lead to the tradeoff between responsibility and rights from which this (and similar) legislation have resulted. This bill, like most things that get people upset, is really a symptom and not
"When a society starts requiring ID cards, it's time to move to another planet." (probably paraphrased, credits to Heinlein)
Seriously though, I have still not been able to figure out the whole "privacy" debate. All the information that is on these cards, as far as I can tell, including address, is information that can be publicly observed. Of course, this raises the question "should it be legal for someone to follow someone around to determine where they live?"
Where you live isn't necessarily a private piece of information, but I can understand the desire people have to not make that information easily available to anyone who might want it. The plain fact of the matter is, there isn't really any such thing as privacy except where there is no possibility of observation.
The dilemma faced by legislators - and the average citizen - is how do you know if people are telling the truth? How do you ensure "trust"? It's a pain in the rear in modern society - it used to be that you lived your life in a small town where you knew the entire town, and when outsiders came in they were treated with suspicion until they were around for long enough with demonstrated character to be trusted.
That is, in fact, the only way to build trust: continued demonstration of certain behavior. This isn't even a guarantee of future behavior, which is the nasty caveat. So, as far as I see it, at best any new type of ID will be a neutral thing. In reality, it will probably carry some nominal fee and so not be good, and it will also probably be abused by certain people or organizations.
The thing is, society is based on trust, and all this type of thing demonstrates is that people are less likely to trust than in the past. The other interesting thing is that you really cannot legislate trust, or behavior for that matter. You can only build trust, and you can only punish or reward behavior. Those are the only controls in society: reward and punishment. It's the unfortunate reality of the world in which we live.
The really interesting thing is they measured system power consumption, not chip consumption. They specified that the power supplies were the same, but the systems have different specs.
It's hardly accurate to judge a CPU's performance based on a "power drawn at the wall" measurement.
I actually hate upgrading certain things - software (especially MS Office apps - where the heck did they move that setting? What's with help trying to connect to the Web?), cell phones (mine's still from 2001 - and no I don't need a camera, wireless, GPS, web-browsing, virus-catching phone thank you!), and automobiles.
Just because they make new cars every year doesn't mean mine doesn't do its job...
I went hunting to find out what the Conjecture is since it appears to be so important, and stumbled across this
It appears that this was already proved in 1976 and is now known as the Quillen-Suslin Theorem.
I wonder, is there a second Serre's Conjecture, or do people not do research any more to see if their work has already been done? Every link I can find for Serre's Conjecture or Quillen-Suslin Theorem indicates that it has already been proved (Quillen got the Fields medal in 1978).
I think people misunderstand what happens when code is compiled. Compiling is not "the compiler uses the source code as instructions to produce an executable"; it's merely a translation of human-readable instructions into computer-readable instructions. I can "read" code and produce the same results by stepping through by hand; the executable code does the same thing (generally much faster). In this sense, the code *IS* the final product; the Reeves article incorrectly equates compiling to building. The "building" is the writing of the code. Compiling is more like translating a book from English to some other language.
When I use the blueprints for an automobile to build the automobile, I get something different than the blueprints. I cannot use the blueprints to emulate the functionality of the vehicle. The blueprints are instructions to build the vehicle.
In software, the design is the thing which tells me how to write the code (have you ever tried to read code and find out what the function is supposed to do? generally you can only know what it does, not what it's supposed to do. Sometimes you get lucky and the design is written in the comments, but that's rare; generally comments just say "we watch out for overflow here" or something like "use pointer rather than array lookup to avoud some tricky thing" - comments are usually descriptive of what is going on, not why). If I have a good design I can write it in any language and meet the same requirements. That's a good litmus test for software: if it depends on a language, it's not a pure design. If you have to figure out what's going on to translate into another language, you're in implementation rather than design.
I will grant, however, that there are some difficult situations when you have a requirement "you shall use language X for this project", or "we decided to use language X to meet these requirements" - what happens if that requirement changes halfway through and your "design" was language specific? You're hosed. Good designs are language transparent.
Remember, the goal isn't to produce an application, the goal is to meet the requirements. The design tells you how you are going to meet the requirements ("have a text grid input box" and, at the next level, "have a function that draws a text grid input box") and the code fulfills the design ("textgrid.draw()"). (Note that some design decisions become requirements for a lower level, such as function calls, interfaces, etc.). Code should only be implementation.
Program does not dump if an alpha value is entered where a numeric is expected
Okay, I'll make the program erase all your files, hack into your bank, and transfer the balance to my offshore accounts when I get an alpha value when a numeric was expected.
This meets your requirement; the program didn't "dump". *grin* Hopefully that illustrates the dangers of most "not" requirements.
The best way to write the requirement you're looking for in this instance is something like:
"Ignore alpha values where a numeric is expected."
Or, "If an alpha is given where a numeric was expected, ignore all following input up to [some delimeter].
Or, perhaps, "If an alpha value is given when a numeric is expected, display an error and get the input again." The general idea is you want to define the requirement and the bounds of operation; "not" requirements are unbounded.
I will grant, however, that sometimes you want a "not" requirement; this discussion has more details on 'not requirements' and rjh points out that sometimes folks use not requirements to prohibit things but purposefully allow anything else; in my opinion this is very dangerous and should only be used very rarely.
I agree that RFCs are requirements documents, but if you ever see a requirement "this feature SHALL NOT do such-and-so", reword it immediately. There is no way to test that somehow, somewhere in the future, the code does not do something weird. In fact, a not requirement means that anything other than what you excluded is allowed to happen. Here's a simple example.
Bad requirement: "The feature shall not process invalid commands."
Good requirement: "The feature shall ignore invalid commands."
So, to meet the first (bad) requirement, I could do anything with the invalid command - like sell it to aliens, put it on the output pins, treat it like a function call, overwrite the stack, rob a liquor store, pretend the commands were valid...and I would meet the requirement. See the danger there? (That is, of course, ignoring the fact that how can you even determine if an invalid command is invalid without processing it in the first place?)
The second (good) requirement really says what you want the feature to do - the feature must ignore invalid commands to meet the requirement. It can't pass go, it can't collect $200, it can't roll again.
Hopefully this illustration will reduce one of the nasty trickeries of requirements...
"The software design is not complete until it has been coded and tested."
I would have to disagree with this; a design is complete when it meets all requirements. A design can only be shown to be complete when it passes all testing; a subtle difference, but one that's come to my attention as being very important.
I have to agree with the statement about traceability though. One of the worst things I've had to deal with is getting a specification document that does some stuff and then have to write the requirements "that would result in this design if we started with those requirements." This is endemic to all industries: ill-formed or ill-stated requirements. I'm always amazed at how many "requirements" are either designs or implementations or are not testable or aren't requirements at all. Even more entertaining are tests that don't test in a way that proves requirements are met...
If I had to enumerate what makes good design the list would have to include:
DO NOT START DESIGN UNTIL YOU HAVE THE REQUIREMENTS (yes, I know there are exceptions, but you should at least have *most* of the requirements first).
Have a good requirements document: everything is actually a requirement (not a design or implementation) and is testable (if you have the word "not" in it, it's not testable, for instance).
Make sure the design is design and not implementation (design is "sum two numbers and check for overflow"; implementation is "temp32 = x16+y16; if temp32 > MAX16 then result16 = MAX16 else result16 = x16+y16;). Put another way, despite the popular writings I've seen lately to the contrary, CODE IS NOT DESIGN (any more than a car is the design of the car).
Make sure you can test that THE DESIGN MEETS THE REQUIREMENTS (which is subtly different than "does the design do what I designed it to do?"). If the design doesn't satisfy the requirements, it can never be a "good design".
Separation of responsibility. You mentioned XP above where "the designer is the coder is the tester" which is just bad practice in my experience. My company *strongly* discourages the designer to be the coder, or the coder to be the tester (the designer can be the tester though, and this often makes sense). This is because there are inevitable blinders that you put on when coding your own design or testing your own code.
Ok, that wasn't an exhaustive list by any means, but I think those are the key points. To summarise: have good requirements, separate requirements from design from implementation, and have many eyes looking at things throughout the whole process.
I don't know that the bankruptcy bills are all about helping the "ultra-wealthy"; I think this is one of those difficult areas where the law is trying to promote better finances by making the penalty for poor finances more harsh. You can argue either way on this one quite effectively, but I'd rather have laws that actually encourage good behavior / discourage poor behavior than laws that artificially put restrictions on economic processes (like service regulations, misused tariffs, etc.)
Incidentally, the lawmakers aren't concerned at all about the interests of large corporations and the ultra-wealthy; they are concerned (for the most part-there are usually exceptions to any rule) with making themselves ultra-wealthy.
No, it's not a failure to prevent offshoring. The failure was in not adapting to the changing marketplace (where the marketplace here is "providing manufacturing services").
If the [unions] had promoted eduction, efficiency, and working to balance benefits with long-term solvency rather than "what's best for me right now or when I retire?", the shift to cheaper commodity parts wouldn't be an issue; the "local" high-value work has changed and these folks didn't see it (in fact, "cars" in some markets (e.g., the US) are actually pretty close to becoming commodity based on price and consumer trends - people don't keep cars long enough any more, they are almost treated as disposable).
Actually, this is only good in the long run, contrary to the other post here on being bad in the long run due to "monopoly" development.
In the very short term it's great for consumers because prices are low. However, in the medium term, a slew of jobs will be deprecated in non-Indo-Chinese nations as the industries relocate. This will cause all sorts of economic and political headache as people will fight the change with tariffs, stressing the system which will then snap nastily when all local demand will vanish and companies go belly-up. Those folks who have enough foresight will work to develop new industries that provide the higher value required to support "western" wages. So, eventually things will shift again.
This is simply the economic cycle on a global scale instead of many small local ones; when any area gets an advantage, wealth shifts there for a while, but it will eventually shift somewhere else again (maybe South America? who knows...)
Savings are only great, also, if people use those savings to save and hedge against disruptions, not if they use it to buy more expensive luxury items and to improve education to better cope with change.
Yes, I could see how you'd call that out separately instead of lumping it in with (1). Strictly speaking, it is (1) because there are situations where the code doesn't do what it was designed to do. Oddly enough, your (0) also incorporates stuff that I cite in (2).
However, I'd posit that a spec cannot be "well written" if it does not account for all possibilities. (I'm picky like that).
I agree with your statement that most people don't understand the purpose of a design discussion, as well as the (lack of) separation between design and code. Simply stated, people often forget that there is an important but subtle distinction among requirements, design, and implementation. If you mess those up, you get worlds of hurt...
I'm not that familiar with how DNS works (other than, "hey DNS server, give me the address for xyz.com" and it spits back either an address or "I've never heard of that"), but it appears you're saying that if I try to get an IP address for "foo.com" some DNS server will tell me I really wanted "google.com"? I don't understand how that's possible.
Or, do you mean that I send on some information like "I want foo.com and I once got it at 1.2.3.4 - is this right?" and the DNS responds with "well, I think 1.2.3.4 belongs to google.com and foo.com is at 10.9.8.7"? At that point, the way I see it, it becomes really difficult to tell what name goes with what address without some physical mechanism. And that, of course, is the whole issue of "remote security".
This is great at explaining what this is, but why could this happen?
Is this a poor implementation of the DNS spec, or is the DNS spec itself to blame for allowing such "poisoning" to occur?
In my experience, software issues occur for one of two reasons:
"Broken" code: The code doesn't do what you think it should- for instance, a function is supposed to return the sum of two numbers but it returns the difference. These errors are actually not that common in my experience (probably because it is easy to test against).
Bad communication / misuse of code: there's a function that is designed to add two numbers, but you think it returns the difference, and you use the results incorrectly. Also included in this category are the "The software does X, but we really wanted it to do Y even though we told you something else," and "We changed the interface with that, but [didn't tell anyone] or [you didn't read the documentation]" type of errors, as well as poor specification processes: for instance, a spec that says "write a function that averages numbers" but doesn't tell how to handle overflows is a "communications" bug in that information is left out. These are the nasty errors, because it is not feasible to reliably test that "people are communicating properly." Note: I'd also include "malicious misuse of code" in this section, becuase it's basically people lying about what the software does.
10k bbl/day is not even worth it - world demand is ~84000k bbl/day. 10k bbl is decimal dust. About.01%, to be exact. This isn't going to do anything for the environment or the price of oil.
Ok, well, it will do something, but there are much less intrusive things that could be done than screwing with the clock system.
The way I see it, we shouldn't even have time zones - I hate having to convert times to have meetings with colleagues across the pond. If a meeting is at 13:30, it should be at 13:30 everywhere... who cares if I happen to work from 8:00 to 17:00 when my colleagues work 4:00 to 13:00? I believe it's called "shifts", isn't it?
Did you ever think that maybe there are "security" issues with posting accurate street-map satellite images of countries on the 'net? This probably explains why the images are "several" years old, and why Google might not have had the ability to get non-US maps.
This "plug-in framework" mentioned in the article sounds like it's simply an OS-independent OS. Think about it: it registers "plug-ins" that talk to each other using "defined interfaces" and each "plug-in" must be registered with the runtime. How is this different than installing applications and registering them? There are well-defined interfaces between applications, APIs for displaying information, etc.
I find it amusing that the article even calls the plug-in manager the "kernel". It seems like the research into this field is basically working on some meta-OS rather than something that will provide real extensibility to a system. All it tells me is that OSs need better interface specifications to provide what folks are looking for and so write their own meta-OS.
I don't think this is a "prior art" issue. I think this is an "obvious to those skilled in the art" issue.
Granted, prior art is a lot easier to prove, but more patents fail the "obviousness" test than the prior art test. The problem with the patent system is that they seem to have forgotten that patentability is not merely "is there prior art?" but "is it useful, novel, and unobvious to those skilled in the art?" Yes, two of those three are subjective, but those are the more imporant of the two in my opinion.
The ideal would be a world where I go tell people what I want and people showing me they can meet that want rather than a world where people are telling me I want what they are offering. Especially if it is "targeted" because they'll be targeting me with things that I might like but don't really need. Insidious!
Slashdot Mirror
Mostly these technologies have to do with the transmission and, I believe, some of the control mechanisms and algorithms. But, despite what you have read in most media outlets, Ford is not buying parts or designs from Toyota (at this time).
Of course, there are still complexities with this - when does public information become sensitive? How do you deal with that aspect of things?
My personal opinion is that simpler is better - the less "information" is required to do something, and the less somethings that are necessary to do, the less risk there is of something being sensitive. For instance, if the only way to get your money was from a bank, in person, where you open your account with someone and they take a picture of you and have it in the back so when the employees leave, and only you can change that picture in person, any other information is not sensitive (of course, a theif who really wanted could impersonate you, but that's a lot more difficult than most theives would consider attempting). It's only when you want to do things "remotely" (i.e., "with convenience") that sensitivity becomes an issue. Think about computers - security is much simpler if you actually have to be at a computer terminal to get information than over a network, because the best a network can do is check to see if you have the right passwords / encryption / or whatever - and those things do not guarantee that you are "you".
This is all about another tradeoff - convenience versus security. I don't think it's possible to have both at high levels. As far as I can tell, at any rate ;)
Interesting example, and here's the dilemma: while I agree that such things tend to "creep people out", what is the fundamental thing that an "anti-stalking law" is addressing? Is it the "peace of mind" of citizens? If so, there has to be something in the law that clearly, objectively defines what "peace of mind" is. You can't claim that people have the right to have their "happiness" protected, because some people have recognized "conditions" such that violence makes them happy. (Yes, I'm using reductio ad absurdum here.) This is not to say that I agree that people should be allowed to stalk or anything; I'm just saying it's not that easy to write laws that prevent this type of thing. However, I'm not sure how Real ID is the same as being stalked; it just makes it easier for people who want your information to get it. People who really want your information know where to look, and it's not in your shredded paper. Public records are, well, public.
I agree that mechanical enforcement of identification is inferior to "personal" enforcement. This is mostly because "mechanical" means have to follow rules, and are therefore only as good (or bad) as those rules. However, I think the reason people are relying on these mechanical means is a complicated issue that includes things like liability, "personal rights," and things that many people advocate: machines don't care about your ethnicity, they just care about some number in your database. They don't even care what the rule about the number is, they just coldly and consistently apply those rules to those numbers.
The interesting thing is that in these "doomsday" scenarios about restricting rights and requiring cars that require identification and all that is that, at some point, the populace will start to vote down things, and call for reform. Assuming that the governmental processes that set up the nation are still followed, things will be corrected. The only reason, in the US at least, that "rights" are removed is because the public doesn't care enough about them to make their voice heard in voting. If people want to make cars that don't have these gadgets and the law requires it, the populace needs to change the laws. It may not be fast-food quick or easy to do so, but it can be done.
I'm more against the philosophies of life that lead to the tradeoff between responsibility and rights from which this (and similar) legislation have resulted. This bill, like most things that get people upset, is really a symptom and not
Seriously though, I have still not been able to figure out the whole "privacy" debate. All the information that is on these cards, as far as I can tell, including address, is information that can be publicly observed. Of course, this raises the question "should it be legal for someone to follow someone around to determine where they live?"
Where you live isn't necessarily a private piece of information, but I can understand the desire people have to not make that information easily available to anyone who might want it. The plain fact of the matter is, there isn't really any such thing as privacy except where there is no possibility of observation.
The dilemma faced by legislators - and the average citizen - is how do you know if people are telling the truth? How do you ensure "trust"? It's a pain in the rear in modern society - it used to be that you lived your life in a small town where you knew the entire town, and when outsiders came in they were treated with suspicion until they were around for long enough with demonstrated character to be trusted.
That is, in fact, the only way to build trust: continued demonstration of certain behavior. This isn't even a guarantee of future behavior, which is the nasty caveat. So, as far as I see it, at best any new type of ID will be a neutral thing. In reality, it will probably carry some nominal fee and so not be good, and it will also probably be abused by certain people or organizations.
The thing is, society is based on trust, and all this type of thing demonstrates is that people are less likely to trust than in the past. The other interesting thing is that you really cannot legislate trust, or behavior for that matter. You can only build trust, and you can only punish or reward behavior. Those are the only controls in society: reward and punishment. It's the unfortunate reality of the world in which we live.
It's hardly accurate to judge a CPU's performance based on a "power drawn at the wall" measurement.
I actually hate upgrading certain things - software (especially MS Office apps - where the heck did they move that setting? What's with help trying to connect to the Web?), cell phones (mine's still from 2001 - and no I don't need a camera, wireless, GPS, web-browsing, virus-catching phone thank you!), and automobiles.
Just because they make new cars every year doesn't mean mine doesn't do its job...
I wonder, is there a second Serre's Conjecture, or do people not do research any more to see if their work has already been done? Every link I can find for Serre's Conjecture or Quillen-Suslin Theorem indicates that it has already been proved (Quillen got the Fields medal in 1978).
You'd probably be interested in reading my post above; it addresses what I think is an improper use of the construction analogy for code.
When I use the blueprints for an automobile to build the automobile, I get something different than the blueprints. I cannot use the blueprints to emulate the functionality of the vehicle. The blueprints are instructions to build the vehicle.
In software, the design is the thing which tells me how to write the code (have you ever tried to read code and find out what the function is supposed to do? generally you can only know what it does, not what it's supposed to do. Sometimes you get lucky and the design is written in the comments, but that's rare; generally comments just say "we watch out for overflow here" or something like "use pointer rather than array lookup to avoud some tricky thing" - comments are usually descriptive of what is going on, not why). If I have a good design I can write it in any language and meet the same requirements. That's a good litmus test for software: if it depends on a language, it's not a pure design. If you have to figure out what's going on to translate into another language, you're in implementation rather than design.
I will grant, however, that there are some difficult situations when you have a requirement "you shall use language X for this project", or "we decided to use language X to meet these requirements" - what happens if that requirement changes halfway through and your "design" was language specific? You're hosed. Good designs are language transparent.
Remember, the goal isn't to produce an application, the goal is to meet the requirements. The design tells you how you are going to meet the requirements ("have a text grid input box" and, at the next level, "have a function that draws a text grid input box") and the code fulfills the design ("textgrid.draw()"). (Note that some design decisions become requirements for a lower level, such as function calls, interfaces, etc.). Code should only be implementation.
This meets your requirement; the program didn't "dump". *grin* Hopefully that illustrates the dangers of most "not" requirements.
The best way to write the requirement you're looking for in this instance is something like:
"Ignore alpha values where a numeric is expected."
Or, "If an alpha is given where a numeric was expected, ignore all following input up to [some delimeter].
Or, perhaps, "If an alpha value is given when a numeric is expected, display an error and get the input again." The general idea is you want to define the requirement and the bounds of operation; "not" requirements are unbounded.
I will grant, however, that sometimes you want a "not" requirement; this discussion has more details on 'not requirements' and rjh points out that sometimes folks use not requirements to prohibit things but purposefully allow anything else; in my opinion this is very dangerous and should only be used very rarely.
Bad requirement: "The feature shall not process invalid commands."
Good requirement: "The feature shall ignore invalid commands."
So, to meet the first (bad) requirement, I could do anything with the invalid command - like sell it to aliens, put it on the output pins, treat it like a function call, overwrite the stack, rob a liquor store, pretend the commands were valid...and I would meet the requirement. See the danger there? (That is, of course, ignoring the fact that how can you even determine if an invalid command is invalid without processing it in the first place?)
The second (good) requirement really says what you want the feature to do - the feature must ignore invalid commands to meet the requirement. It can't pass go, it can't collect $200, it can't roll again.
Hopefully this illustration will reduce one of the nasty trickeries of requirements...
I have to agree with the statement about traceability though. One of the worst things I've had to deal with is getting a specification document that does some stuff and then have to write the requirements "that would result in this design if we started with those requirements." This is endemic to all industries: ill-formed or ill-stated requirements. I'm always amazed at how many "requirements" are either designs or implementations or are not testable or aren't requirements at all. Even more entertaining are tests that don't test in a way that proves requirements are met...
If I had to enumerate what makes good design the list would have to include:
- DO NOT START DESIGN UNTIL YOU HAVE THE REQUIREMENTS (yes, I know there are exceptions, but you should at least have *most* of the requirements first).
- Have a good requirements document: everything is actually a requirement (not a design or implementation) and is testable (if you have the word "not" in it, it's not testable, for instance).
- Make sure the design is design and not implementation (design is "sum two numbers and check for overflow"; implementation is "temp32 = x16+y16; if temp32 > MAX16 then result16 = MAX16 else result16 = x16+y16;). Put another way, despite the popular writings I've seen lately to the contrary, CODE IS NOT DESIGN (any more than a car is the design of the car).
- Make sure you can test that THE DESIGN MEETS THE REQUIREMENTS (which is subtly different than "does the design do what I designed it to do?"). If the design doesn't satisfy the requirements, it can never be a "good design".
- Separation of responsibility. You mentioned XP above where "the designer is the coder is the tester" which is just bad practice in my experience. My company *strongly* discourages the designer to be the coder, or the coder to be the tester (the designer can be the tester though, and this often makes sense). This is because there are inevitable blinders that you put on when coding your own design or testing your own code.
Ok, that wasn't an exhaustive list by any means, but I think those are the key points. To summarise: have good requirements, separate requirements from design from implementation, and have many eyes looking at things throughout the whole process.Incidentally, the lawmakers aren't concerned at all about the interests of large corporations and the ultra-wealthy; they are concerned (for the most part-there are usually exceptions to any rule) with making themselves ultra-wealthy.
If the [unions] had promoted eduction, efficiency, and working to balance benefits with long-term solvency rather than "what's best for me right now or when I retire?", the shift to cheaper commodity parts wouldn't be an issue; the "local" high-value work has changed and these folks didn't see it (in fact, "cars" in some markets (e.g., the US) are actually pretty close to becoming commodity based on price and consumer trends - people don't keep cars long enough any more, they are almost treated as disposable).
In the very short term it's great for consumers because prices are low. However, in the medium term, a slew of jobs will be deprecated in non-Indo-Chinese nations as the industries relocate. This will cause all sorts of economic and political headache as people will fight the change with tariffs, stressing the system which will then snap nastily when all local demand will vanish and companies go belly-up. Those folks who have enough foresight will work to develop new industries that provide the higher value required to support "western" wages. So, eventually things will shift again.
This is simply the economic cycle on a global scale instead of many small local ones; when any area gets an advantage, wealth shifts there for a while, but it will eventually shift somewhere else again (maybe South America? who knows...)
Savings are only great, also, if people use those savings to save and hedge against disruptions, not if they use it to buy more expensive luxury items and to improve education to better cope with change.
However, I'd posit that a spec cannot be "well written" if it does not account for all possibilities. (I'm picky like that).
I agree with your statement that most people don't understand the purpose of a design discussion, as well as the (lack of) separation between design and code. Simply stated, people often forget that there is an important but subtle distinction among requirements, design, and implementation. If you mess those up, you get worlds of hurt...
Or, do you mean that I send on some information like "I want foo.com and I once got it at 1.2.3.4 - is this right?" and the DNS responds with "well, I think 1.2.3.4 belongs to google.com and foo.com is at 10.9.8.7"? At that point, the way I see it, it becomes really difficult to tell what name goes with what address without some physical mechanism. And that, of course, is the whole issue of "remote security".
Is this a poor implementation of the DNS spec, or is the DNS spec itself to blame for allowing such "poisoning" to occur?
In my experience, software issues occur for one of two reasons:
10k bbl/day is not even worth it - world demand is ~84000k bbl/day. 10k bbl is decimal dust. About .01%, to be exact. This isn't going to do anything for the environment or the price of oil.
Ok, well, it will do something, but there are much less intrusive things that could be done than screwing with the clock system.
The way I see it, we shouldn't even have time zones - I hate having to convert times to have meetings with colleagues across the pond. If a meeting is at 13:30, it should be at 13:30 everywhere... who cares if I happen to work from 8:00 to 17:00 when my colleagues work 4:00 to 13:00? I believe it's called "shifts", isn't it?
Did you ever think that maybe there are "security" issues with posting accurate street-map satellite images of countries on the 'net? This probably explains why the images are "several" years old, and why Google might not have had the ability to get non-US maps.
I hold high standards: I measure room temperature in Kelvin.
I find it amusing that the article even calls the plug-in manager the "kernel". It seems like the research into this field is basically working on some meta-OS rather than something that will provide real extensibility to a system. All it tells me is that OSs need better interface specifications to provide what folks are looking for and so write their own meta-OS.
Granted, prior art is a lot easier to prove, but more patents fail the "obviousness" test than the prior art test. The problem with the patent system is that they seem to have forgotten that patentability is not merely "is there prior art?" but "is it useful, novel, and unobvious to those skilled in the art?" Yes, two of those three are subjective, but those are the more imporant of the two in my opinion.
The ideal would be a world where I go tell people what I want and people showing me they can meet that want rather than a world where people are telling me I want what they are offering. Especially if it is "targeted" because they'll be targeting me with things that I might like but don't really need. Insidious!