Are these people even focused on profit, or share value, or whatever, or are they just getting their jollies from shafting the workers and using profit as just an excuse?
You got it: they are enjoying the feeling of power and using profit as an excuse. All human institutions reflect basic primate (especially chimpanzee) psychology. Hierarchy and attention are the dominant factors in monkey societies. Monkeys who can get the troop's attention are able to move up the social tree more easily, and there is a basic drive to get as high as possible. It "just seems the right thing to do" to your average unreflective monkey.
The big mistake geeks make is to think that technical expertise is more than weakly related to success in the corporate world. Being a charismatic bully is far more likely to get you promoted than techincal capability.
This is not much of a problem so long as we don't let the propoganda that companies spew get to us. Most importantly, the degree of loyalty you owe to your employer is exactly equal to the degree of loyalty your employer shows to you and your fellow-workers. In the case of MS, they have made a very clear statement that arbitrary actions like dropping all contractors for a week are just find. Ergo, it is just fine for contractors to walk without notice or reason--or to just not show up for a week (without pay) for no reason). Of course, most contractors are decent human beings, so they will find more gentle exit strategies, but none of them should have the least compunction regarding leaving. Reciprocity is all.
Google and Yahoo's entire business model is web-based and advertisement based.
And Microsoft's business model is based on the PC as a general-purpose computer rather than a commodity with limited functions. This is extremely fragile. IBMs business model was based on computers as big central resources, and they got eaten alive by Microsoft and Apple in the '80's. It seems to me likely that Google and Yahoo have a chance at doing the same thing to Microsoft.
This is not so much about how clever Balmer or Gates or anyone else is. It is about how technology evolves. The people running IBM weren't stupid. They were just limited in their perspective by their own success, and failed to see how much the world was about to change.
Most people on/. will probably still be using PCs in the next decade. But even today most computers sold to consumers are not general-purpose. They are cell phones or game consoles or PDAs. Smaller, cheaper, special-purpose computers that use the distributed power of the network may actually really be the Next Big Thing this time.
If projects like the $100 laptop thing are successful they could have the unintended consequence of making things like Web appliances viable commodities. General purpose computing would become a relatively specialized market, like mainframes today: still profitable and a viable business, but no where near as profitable as it is for Microsoft today. In those market conditions either MS doesn't have a lot of choice but to to through some very rough financial times.
Both Apple and Microsoft are making moves in the direction of commodity appliances, but Apple is (so far) doing so a lot more successfully.
Python is a terrific prototyping language (and lots of other things besides.) As a C++ coder I've been using it for prototyping stuff that will eventually be integrated into a larger application and therefore MUST be translated to C++. So what I'd like to see is a tool (written in Perl, just for the fun of having a linguistic threesome) that just does a light gloss on Python syntax to get me most of the way to human-readable C++. That would be far more useful (to me) than thsi thing, which sounds more like f2c, whose output could case brain damage in humans and cancer in rats, or possibly the other way around.
I like java (alot really), but nothing beats a good scirpting language, like perl or python, to handle tasks like text manipulation.
You say that like you think Java isn't a scripting language, but an analysis of language features, like anonymous inner classes (which encourage on-the-fly, non-designed extensions to applications) clearly shows that it is more appropriate to scripting than an applications development, particularly if you care about run-time performance (yeah, I know, with the right JVM and stuff Java can go fast--so prove to me that my customers will be running that JVM and that it will support all the language features I need for the specific application I'm building--"can go fast" != "does go fast".)
The article describes the basic things that are wrong with virtually every late project:
Managers who can't handle the truth
Developers or lower level managers who lie to fulfill the psychological needs of managers who can't handle the truth
A marketing-driven schedule culture that declares "drop dead dates", misses them, and nobody dies
Input rather than output focused management (action control vs results control)
Managers who interfere inappropriately with technical decision-making
Excessive project mangement/process burden--the level of process needs to be just right for a project to run effectively, and needs to retuned on a per-project basis by people to whom success is more important than ego
He is describing a sick management culture, one peopled by individuals who are not part of a reality-based community and not aware of their own deficits. Projects run by people like this will always be late and frequently fail completely, because reality doesn't care about management egos.
This is pretty typical of modern management culture. It just shows up more clearly in this case because of the length and size of the project.
such as the temperatures recorded at sites that used to be in rural areas, but are now in suburban or urban areas, due to the growth of cities.
The heat-island effect has been well-handled since the mid-90's. There was a period of about five years where satelite measurements and ground measurements were inconsistent, but now multiple methods, including ice core data, are consistent.
One of the cardinal diagnostics of a crank is that they bring up past disputes and problems as if they had never been resolved, and refuse to look at the details of how they were resolved.
Look at the debate over the Bell Curve or Holocaust revisionism. It doesn't matter that the proponents are ultimately wrong, what's important is that they aren't even allowed to publicly state their positions.
What are these "Bell Curve" and "Holocaust revisionism" things of which you speak?
The significance for the monks was that the Bible was telling them that the earth and heavens were unchanged since Creation and would remain unchanged forever after.
This is not in scripture, but is a belief of classical cosmology, which divided the universe into two major regions, above and below the Moon. Below the Moon change could occur. Above the Moon it was assumed on the basis of no evidence (that is, on faith) that change did not and could not occur. This bit of faith was given a big boost by the Scholastics in the late Middle Ages, but I think its prevalence predated them. So seeing a change occur on the Moon would probably have challenged the monk's beliefs in this regard--it was a little too close to the boundary for comfort.
It wasn't until Tycho Brahe or someone very much like him measured the parallax of a comet and showed definitively that it was above the orbit of the Moon that this false belief really started to diminish, and even then it took quite some time to die.
So Sagan was right to see this event as a challenge to the monk's faith, but he was wrong if he attributed that specific article of faith to the Bible. The evil of faith is not in the source or specific content, but in the mode of belief and the rule of its function.
I have read about robots for ages and i think that the three laws are a load of crap.
Asimov was trying to move the robot-story genre beyond R.U.R. The three laws were a way of doing that.
Unfortunately for him, R.U.R. (and even earlier, Frankenstein) codified for all time the allowed parameters of the robot-story, which have now been adopted as an international standard (ISO 90210). All robot stories must have no more than trivial variations from the following plot:
1) Well-meaning, possibly arrogant but definitely naive maker creates artificial human(s) 2) Artificial humans have deficits that are not entirely unlike those of real humans 3) Optionally, maker can attempt to "improve" artificial humans 4) Artificial humans go mad/get upset and kill real humans by design or accident 5) A long chase scense 6) Real humans triumph, artificial humans die gloriously/pathetically.
That's it. NO OTHER PLOTS ARE ALLOWED.
As an addendum to the standard, all attempts to make derivative works based on Asimov's stories are converted to remakes of R.U.R. The most recent remake of R.U.R. was a film with the Asimovian title "I, Robot".
Drugs are no substitue for real learning, but they can provide an unfair advantage in an artificial situation intended to measure learning, such as a college exam.
This is the problem. College exams are terrible measures of learning. As an old prof of mine once said talking to some first-years in a physics lab: "If I tell you to measure this table, and you lay a tape-measure down on it like so and write down the number and hand it in, I WILL FAIL YOU. You never measure anything just once!"
As a prof I was even more uncomfortable giving exams than I was as a student taking them, because I came to realized that we were making a measurement in a way that we would never condone as scientists. We were making a single measurement on our students and saying it was a good measure of their capacities, which is nonsense.
If marks were objective they'd have error bars.
The "final exam" culture that exists in many modern universities is a product of mass-produced education, and I don't have any particularly good answer to it. We need some relatively simple way of evaluating students and reporting that evaluation to the world, but we take marks way too seriously given the shoddy, unscientific process that produces them.
But so long as we give such unrealistic and unreasonable weight to a few point-measurements of student performance, students will be tempted to use every means available to increase their performance to an unrealistic maximum at those few points.
If you can maintain the military work ethic, you'll probably have an advantage over most of your competitors, at least in the areas of initiative, attention to detail, knowledge of the importance of planning, and ability to prioritize.
Those four things are pretty important, and the last three are basically logistical skills. "Amateurs worry about tactics, professionals worry about strategy, experts worry about logistics."
The U.S. military is generally really good at is logistics, at least operationally. The thing that almost every other organization in the world is really bad at is logistics. Logistical capability is what makes the difference between projects that finish on time and within budget, and the typical clusterfuck that is the modern project team.
There is no magic to the process, and the prevalence of the belief that "all projects finish late" in an organization is a measure of the logistical incompetence of that organization. The size of the organization is in my experience not a big factor in logistical competence. I've worked for very large (Fortune 10) organizations and very small (10 employee) organizations and seen similar problems in both.
Within a large organization there are bound to be pockets of logistical competence--you can identify those parts by the fact that they are resented by the rest of the organization because they always get the easy problems. You know--the ones that seem to be solvable on schedule and without heroics. If you can find a team like that, stick with it and enjoy it while it lasts. They can make work a real pleasure.
I finally got fed up with having my well-being tied to other people's logistical (and sometimes technical) incompetence, so after learning some hard lessons in a failed business partnership I went out on my own, which more than doubled my income and tripled my enjoyment. Trust in yourself, always be willing to try something new, and never be ashamed of your failures: they are your greatest learning opportunities.
If you put a sign in your front yard declaring how much you hate the government, you shouldn't act too surprised when the government reads it.
Yeah, I sent e-mail to some idiot columnist at an American newspaper yesterday because he said that "Americans have a lot to learn from Canada. You don't see any fuss when the RCMP monitor internet chat rooms--not like the fusspots who scream about the NSA intercepting phone calls." I pointed out to the dimwit that Americans could very well learn from Canadians: the RCMP didn't break any laws in their recent terrorist investigation (they have done so in the past, and been smacked on the nose with rolled up newspaper for it.)
I see nothing wrong with governments monitoring public communications. But making any inferences from datamining on those public communications is something only a complete idiot would do.
Lets just hope no-one makes any tiny but significant mistake in describing their experiment, and that all authors take the time to learn this formal language and then use it.
It's worse than that.
The "formality" of a formal language is only in the syntax. Semantically, all languages are informal. Even within a nominally formal field like physics the way individual physicists ascribe meaning to the formalism is radically different. This happens even when doing "normal science", and is much worse when something radical like the language of dynamics is changing the way it did in the early 20th century.
A friend who works with GIS systems in geology puts it this way: "I can send a team out to map an area using a common ontology, and at the end of the day when I bring all their data together I can determine who mapped where, but not what anyone mapped." What simple geological terms like "granite" mean vary sufficiently between individuals that different people will ascribe different boundaries to "the same" structures.
The deep problem here is that all boundaries are fundamentally epistemic in origin--metaphysically the world is a complex soup that can be chopped up in an infinite number of self-consistent ways. Some of those ways are more useful to creatures like us than others, and science is a process of figuring out consistent and useful boundaries. So the very notion of a static ontology is therefore of limited utility--not useless by any means, but prima facie limited to relatively small slices of reality over relatively short periods of time.
The second rule of the Internet Dating Club is that EVERYBODY lies.
The third rule of the Internet Dating Club is that if it's your first date, you MUST confess. Besides, at that point it becomes obvious that you really have more years, more weight, less hair and fewer teeth than you claimed online.
As near as I can tell from my own experiences and the tales told by the women I've met online, dishonesty is about equally distributed between men and women. The sites with the highest level of honesty are the free ones like plentyoffish.com and okcupid.com. I'm not sure why this is--maybe because the people there have less invested in the whole process and realize that the net is a great way to make contact and and a lousy way to get to know anyone.
If you really want to scare someone from 1920, put him in a car and hit the expressway. They'd faint dead away.
Yeah, I was just thinking about a comment my father (born in 1921) once made, that when he was kid it was a commonplace to believe that high speeds alone could have deadly effect. He knew people who literally believed that when someone fell from a height they were dead before they hit the ground, killed by the speed of their fall.
Despite the fact that trains had exceeded 100 MPH in the late 1800's, and aircraft were going much fast than that by the end of the '20's, speed was still an exotic experience. The idea of people routinely going at 65 MPH or more in dense traffic would just amaze a time traveller from that era, far more than cell phones or holding cameras oddly.
Commonplace female executives and other professionals, particularly female doctors treating male patients, would shock our imagined traveller. Fowler makes an impassioned plea for the use of feminine professional terms like "doctoress" and "lawyeress" in, I think, The King's English, because although he could imagine intellectually that women might enter those professions in larger numbers in the future he could not imagine that they would ultimately be treated just like any other member of those professions.
Universal mixed-race teams in professional sports would be shocking, as would universal mixed-race schooling. The civil rights movement really did change things.
The ubiquity of bare skin would be another shock. I was walking by a public park the other day and blissfully noted a couple of young women sunbathing in bikinis that might between them be sewn together into something the size of an ordinary handkerchief.
The most shocking thing of all, though, would be that we went to the Moon half a dozen times and then just stopped.
One of my minor crusades on/. is to encourage people--especially astonomers--to stop talking about "the" dark matter. There are several different dark matter problems, and they may well have quite different solutions, some of them a lot more exotic than others. Galactic dark matter is (at least potentially) baryonic. Dark matter on larger scales is almost certainly not baryonic unless we've really goofed on the whole primordial nucleosynthesis thing.
The discovery of these small objects suggests that the initial mass function could have a much stronger low-mass tail than anyone thinks plausible, so despite the MACHO results there is still a chance for a baryonic solution to the galactic dark matter problem.
Companies don't want people who can get the work done, they want people who can get the work done professionally.
No, they want people who can make managers feel good.
Doing a good, professional job is well down the list of things that companies want. Far more important are things like: does not make their manager feel stupid, even when the manager makes stupid suggestions; does good work in such a way that their manager can take credit for it; does not point out stupid management decisions to management's face; does not point out how poor policy decisions have created a situation that is now being solved by implementing even worse policy decisions because they waste resources on short-term band-aid solutions rather than invest resources in longer-term corrective action; and so on.
Young kids don't have the political savvy to realize this, and therefore are only hired in boom times. Besides, managing young kids doesn't give managers anything like the ego-boost that managers get out of older people. There's nothing a semi-competent MBA with adequacy issues loves more than managing people who are smarter, more technically capable and older than their manager.
When I read the New Testament, one thing that really stands out to me is the emphasis Jesus placed on always asking questions. He never told his followers to obey him obediently. He wanted them to question his actions and words.
Mark 10:2-12: "And the Pharisees came to him, and asked him, Is it lawful for a man to put away his wife? tempting him. And he answered and said unto them, What did Moses command you? And they said, Moses suffered to write a bill of divorcement, and to put her away. And Jesus answered and said unto them, For the hardness of your heart he wrote you this precept. But from the beginning of the creation God made them male and female. For this cause shall a man leave his father and mother, and cleave to his wife; And they twain shall be one flesh: so then they are no more twain, but one flesh. What therefore God hath joined together, let not man put asunder. And in the house his disciples asked him again of the same matter. And he saith unto them, Whosoever shall put away his wife, and marry another, committeth adultery against her. And if a woman shall put away her husband, and be married to another, she committeth adultery."
There is no questioning nor observation nor experiment here. There is a bald pronouncement: divorce is forbidden (there is a hotly contested description of the same exchange in Matthew that may permit divorce on some grounds if we could only figure out how to translate the Greek word "pornei" unambiguously.)
The key to this passage is the question of scriptural authority vs the authority of Christ. Jesus is saying that even though the scriptures permit divorce, God doesn't approve of it and the time has come to end it. Jesus is claiming arbitrarily and without a shred of empirical evidence that God wants married people to stay that way. Period. He does not mention social ills or practical problems. He simply invokes what God wants. This why Christianity is religion, not science.
There is no practical way within the Christian framework to challenge Jesus' flat-out prohibition on divorce. To do so you either have to avail yourself of Matthew's ambiguous loophole, or you have to deny the validity of Christ's words in this instance, possibly invoking the fact that we know prohibiting divorce can lead to various social ills, the exploitation and/or battering of spouses, etc, and Jesus was clearly against that kind of thing.
But once you have done that you are well on your way down the interpretive slippery slope that leads to secular humanism. You'll find lots of friendly people ready to greet you with open arms when you reach the bottom!
I was skeptical then, I'm skeptical now. Tools like the ones described are useful, but they're not foolproof, and they hardly supplant the intuition and "art" that is programming.
I once studied "Z", a specification language that was supposed to eventually be able to feed automatic correctness checkers. I realized how bad the language was when one of the canonical examples required that the design of the code itself be contaminated by the constraints of the specification language.
For some very narrowly defined problem domains I'm sure tools like this are useful, but I'm equally sure that the specification of a useful, general-purpose tool of this type would grow in complexity until it finally collapsed under its own weight. The final specification of an effective design evaluation tool would read, "Entity with intelligence, understanding, taste and good judgement."
automatic code generation is even more of a joke (at absolute best, it saves you 5 minutesof typing boilerplate class skeletons).
False.
I have written a series of XML-based code-generators over the past five or six years, and found them increasingly useful. I started out with a big dream: represent an application as a narrative and tie the document structure (DTD) to the program structure in a deep and powerful way.
Like a lot of big dreams, it didn't survive contact with reality (or with other developers). After seeing the framework gutted in a re-write by a developer who needed to "simplify" it to understand it, I re-wrote it for my own use without such grand ambitions but with a lot more practicality.
Propertly done, generated code gives you a lot more than a five-minute savings. It gives you all of your serialization code, which I particularly hate writing, and it gives you some access to a higher-level modelling language. Admittedly XML is not exactly god's gift to data modelling, but it's better than nothing (I actually tried developing an implementation of the code-generator in XSLT, but have subsequently decided that I'd rather chew my own leg off than go there.)
I treat the code generator like a particularly intelligent junior developer--one who is capable of understanding my design and writing code that implements that design and conforms to my company's coding standards and serializes the classes to well-formed XML. This kind of thing is also useful for prototyping, and useful for exploring the conceptual aspects of the design. I will often rev the XML specifications quite a few times before generating any code, simply in the process of getting the representations and relationships right.
A well-written code generator is a valuable tool in any developer's toolkit. Mine is not yet ready for prime time (no documentation to speak of, and I'm too busy with clients right now to write any) but I'm sure there are others out there that are just as good.
I'm a Canadian working in the U.S. on a TN visa. My I-94 has a chip. Big deal. I can always wrap it in foil if I don't want to be tracked inside the U.S., and it's a convenience crossing the border because by the time I talk to the guy in the booth they know who I am and what I'm doing there.
Chips in documents are unobtrusive and innocuous, because you can always shield them.
Chips in people are violations of certain inalienable rights, and if the U.S. were ever to go forward with this programme it would be an isolationists dream. The only people entering the country would be either illegal or desperate. No one with any opportunity to avoid it would ever go near the U.S. again.
And on this point, I agree: if I buy a security product that claims "secure file storage", and I find out that they implement this single-DES encryption -- and espeicially if my data is compromised as a result -- the vendor should be liable. They made a false claim!
While I agree that single-DES is not very secure, it is more secure than no encryption at all and therefore may warrant being called "secure". Without a truly vast and Byzantine body of law to define what various words mean, such claims are without value.
In other areas where product liability is at issue there are two solutions: government mandated standards and inspections, and the aforesaid vast and Byzantine body of law. These have given us "USDA Grade A" and "Made with REAL FRUIT" labelling, respectively.
I personally think it's about a decade too soon for this kind of thing in a field as fluid and poorly categorized as software, and it always will be.
Is it that the border/immigration laws themselves are unpalatable? If so they should be changed.
The problem is that border/immigration laws will not make America substantially more secure because any point-of-entry security protocol is bound to be porous, and once inside the barrier there is no practical way of identifying illegal immigrants. Bush's laughable proposal of "tamperproof IDs for immigrants" neglects to account for the fact that immigrants are perfectly capable of faking citizen's IDs. Instituting universal, biometric IDs for citizens is a much, much harder political sell than for immigrants, so it is likely that most illegal immigrants will get fake citzen's IDs of one kind or another.
Furthermore, focusing on the border as if a wall could keep THEM out tends to make the whole security issue one of US vs THEM, which is silly. Timothy McVeigh was an American. The London bombers were Britons. Fighting terrorism is not primarily about securing borders. It is primarily about good police-work within healthy, supportive, open communities. Building walls and demonizing illegal immigrants does not further those ends.
To put my point about border security in geek-friendly terms, when building a secure, robust system there are two ways of dealing with pre-condition checking. The first is to do a one-time check at the entry of a block where a condition is required, and then let everything within that block proceed on the assumption that the condition has been met. The other is to check the condition immediately before it gets used, every single time.
The former is less resource-intensive, but the latter is the only way to be sure. For example, I've seen code that does something like this:
and someMethod() merrily dereferences pFoo without checking it because the developer "knows" it has already been checked. But of course at some future date some poor maintenance coder will call someMethod() from somewhere else without checking, and things will blow up.
For real robustness (and real security) defense-in-depth is required. But in human societies that means a police state, which is far more dangerous to the life and liberties of citizens than the threats they are intended to counter. Remember--terrorism kills fewer people each year in the United States than falling down, suicide or HIV (in most years it is vastly fewer, but fewer even in 2001).
Stephen Flowers' "Software Failure: Management Failure" is a must-read for anyone who is serious about software development. Based on about ten case studies, mostly of large IT projects, he identifies a set of factors that are strong failure indicators. In my experience the factors apply to non-IT projects as well, like ordinary desktop application development.
Slashdot Mirror
Are these people even focused on profit, or share value, or whatever, or are they just getting their jollies from shafting the workers and using profit as just an excuse?
You got it: they are enjoying the feeling of power and using profit as an excuse. All human institutions reflect basic primate (especially chimpanzee) psychology. Hierarchy and attention are the dominant factors in monkey societies. Monkeys who can get the troop's attention are able to move up the social tree more easily, and there is a basic drive to get as high as possible. It "just seems the right thing to do" to your average unreflective monkey.
The big mistake geeks make is to think that technical expertise is more than weakly related to success in the corporate world. Being a charismatic bully is far more likely to get you promoted than techincal capability.
This is not much of a problem so long as we don't let the propoganda that companies spew get to us. Most importantly, the degree of loyalty you owe to your employer is exactly equal to the degree of loyalty your employer shows to you and your fellow-workers. In the case of MS, they have made a very clear statement that arbitrary actions like dropping all contractors for a week are just find. Ergo, it is just fine for contractors to walk without notice or reason--or to just not show up for a week (without pay) for no reason). Of course, most contractors are decent human beings, so they will find more gentle exit strategies, but none of them should have the least compunction regarding leaving. Reciprocity is all.
Google and Yahoo's entire business model is web-based and advertisement based.
/. will probably still be using PCs in the next decade. But even today most computers sold to consumers are not general-purpose. They are cell phones or game consoles or PDAs. Smaller, cheaper, special-purpose computers that use the distributed power of the network may actually really be the Next Big Thing this time.
And Microsoft's business model is based on the PC as a general-purpose computer rather than a commodity with limited functions. This is extremely fragile. IBMs business model was based on computers as big central resources, and they got eaten alive by Microsoft and Apple in the '80's. It seems to me likely that Google and Yahoo have a chance at doing the same thing to Microsoft.
This is not so much about how clever Balmer or Gates or anyone else is. It is about how technology evolves. The people running IBM weren't stupid. They were just limited in their perspective by their own success, and failed to see how much the world was about to change.
Most people on
If projects like the $100 laptop thing are successful they could have the unintended consequence of making things like Web appliances viable commodities. General purpose computing would become a relatively specialized market, like mainframes today: still profitable and a viable business, but no where near as profitable as it is for Microsoft today. In those market conditions either MS doesn't have a lot of choice but to to through some very rough financial times.
Both Apple and Microsoft are making moves in the direction of commodity appliances, but Apple is (so far) doing so a lot more successfully.
Python is a terrific prototyping language (and lots of other things besides.) As a C++ coder I've been using it for prototyping stuff that will eventually be integrated into a larger application and therefore MUST be translated to C++. So what I'd like to see is a tool (written in Perl, just for the fun of having a linguistic threesome) that just does a light gloss on Python syntax to get me most of the way to human-readable C++. That would be far more useful (to me) than thsi thing, which sounds more like f2c, whose output could case brain damage in humans and cancer in rats, or possibly the other way around.
I like java (alot really), but nothing beats a good scirpting language, like perl or python, to handle tasks like text manipulation.
You say that like you think Java isn't a scripting language, but an analysis of language features, like anonymous inner classes (which encourage on-the-fly, non-designed extensions to applications) clearly shows that it is more appropriate to scripting than an applications development, particularly if you care about run-time performance (yeah, I know, with the right JVM and stuff Java can go fast--so prove to me that my customers will be running that JVM and that it will support all the language features I need for the specific application I'm building--"can go fast" != "does go fast".)
The article describes the basic things that are wrong with virtually every late project:
He is describing a sick management culture, one peopled by individuals who are not part of a reality-based community and not aware of their own deficits. Projects run by people like this will always be late and frequently fail completely, because reality doesn't care about management egos.
This is pretty typical of modern management culture. It just shows up more clearly in this case because of the length and size of the project.
such as the temperatures recorded at sites that used to be in rural areas, but are now in suburban or urban areas, due to the growth of cities.
The heat-island effect has been well-handled since the mid-90's. There was a period of about five years where satelite measurements and ground measurements were inconsistent, but now multiple methods, including ice core data, are consistent.
One of the cardinal diagnostics of a crank is that they bring up past disputes and problems as if they had never been resolved, and refuse to look at the details of how they were resolved.
Look at the debate over the Bell Curve or Holocaust revisionism. It doesn't matter that the proponents are ultimately wrong, what's important is that they aren't even allowed to publicly state their positions.
What are these "Bell Curve" and "Holocaust revisionism" things of which you speak?
The significance for the monks was that the Bible was telling them that the earth and heavens were unchanged since Creation and would remain unchanged forever after.
This is not in scripture, but is a belief of classical cosmology, which divided the universe into two major regions, above and below the Moon. Below the Moon change could occur. Above the Moon it was assumed on the basis of no evidence (that is, on faith) that change did not and could not occur. This bit of faith was given a big boost by the Scholastics in the late Middle Ages, but I think its prevalence predated them. So seeing a change occur on the Moon would probably have challenged the monk's beliefs in this regard--it was a little too close to the boundary for comfort.
It wasn't until Tycho Brahe or someone very much like him measured the parallax of a comet and showed definitively that it was above the orbit of the Moon that this false belief really started to diminish, and even then it took quite some time to die.
So Sagan was right to see this event as a challenge to the monk's faith, but he was wrong if he attributed that specific article of faith to the Bible. The evil of faith is not in the source or specific content, but in the mode of belief and the rule of its function.
I have read about robots for ages and i think that the three laws are a load of crap.
Asimov was trying to move the robot-story genre beyond R.U.R. The three laws were a way of doing that.
Unfortunately for him, R.U.R. (and even earlier, Frankenstein) codified for all time the allowed parameters of the robot-story, which have now been adopted as an international standard (ISO 90210). All robot stories must have no more than trivial variations from the following plot:
1) Well-meaning, possibly arrogant but definitely naive maker creates artificial human(s)
2) Artificial humans have deficits that are not entirely unlike those of real humans
3) Optionally, maker can attempt to "improve" artificial humans
4) Artificial humans go mad/get upset and kill real humans by design or accident
5) A long chase scense
6) Real humans triumph, artificial humans die gloriously/pathetically.
That's it. NO OTHER PLOTS ARE ALLOWED.
As an addendum to the standard, all attempts to make derivative works based on Asimov's stories are converted to remakes of R.U.R. The most recent remake of R.U.R. was a film with the Asimovian title "I, Robot".
Drugs are no substitue for real learning, but they can provide an unfair advantage in an artificial situation intended to measure learning, such as a college exam.
This is the problem. College exams are terrible measures of learning. As an old prof of mine once said talking to some first-years in a physics lab: "If I tell you to measure this table, and you lay a tape-measure down on it like so and write down the number and hand it in, I WILL FAIL YOU. You never measure anything just once!"
As a prof I was even more uncomfortable giving exams than I was as a student taking them, because I came to realized that we were making a measurement in a way that we would never condone as scientists. We were making a single measurement on our students and saying it was a good measure of their capacities, which is nonsense.
If marks were objective they'd have error bars.
The "final exam" culture that exists in many modern universities is a product of mass-produced education, and I don't have any particularly good answer to it. We need some relatively simple way of evaluating students and reporting that evaluation to the world, but we take marks way too seriously given the shoddy, unscientific process that produces them.
But so long as we give such unrealistic and unreasonable weight to a few point-measurements of student performance, students will be tempted to use every means available to increase their performance to an unrealistic maximum at those few points.
If you can maintain the military work ethic, you'll probably have an advantage over most of your competitors, at least in the areas of initiative, attention to detail, knowledge of the importance of planning, and ability to prioritize.
Those four things are pretty important, and the last three are basically logistical skills. "Amateurs worry about tactics, professionals worry about strategy, experts worry about logistics."
The U.S. military is generally really good at is logistics, at least operationally. The thing that almost every other organization in the world is really bad at is logistics. Logistical capability is what makes the difference between projects that finish on time and within budget, and the typical clusterfuck that is the modern project team.
There is no magic to the process, and the prevalence of the belief that "all projects finish late" in an organization is a measure of the logistical incompetence of that organization. The size of the organization is in my experience not a big factor in logistical competence. I've worked for very large (Fortune 10) organizations and very small (10 employee) organizations and seen similar problems in both.
Within a large organization there are bound to be pockets of logistical competence--you can identify those parts by the fact that they are resented by the rest of the organization because they always get the easy problems. You know--the ones that seem to be solvable on schedule and without heroics. If you can find a team like that, stick with it and enjoy it while it lasts. They can make work a real pleasure.
I finally got fed up with having my well-being tied to other people's logistical (and sometimes technical) incompetence, so after learning some hard lessons in a failed business partnership I went out on my own, which more than doubled my income and tripled my enjoyment. Trust in yourself, always be willing to try something new, and never be ashamed of your failures: they are your greatest learning opportunities.
If you put a sign in your front yard declaring how much you hate the government, you shouldn't act too surprised when the government reads it.
Yeah, I sent e-mail to some idiot columnist at an American newspaper yesterday because he said that "Americans have a lot to learn from Canada. You don't see any fuss when the RCMP monitor internet chat rooms--not like the fusspots who scream about the NSA intercepting phone calls." I pointed out to the dimwit that Americans could very well learn from Canadians: the RCMP didn't break any laws in their recent terrorist investigation (they have done so in the past, and been smacked on the nose with rolled up newspaper for it.)
I see nothing wrong with governments monitoring public communications. But making any inferences from datamining on those public communications is something only a complete idiot would do.
Lets just hope no-one makes any tiny but significant mistake in describing their experiment, and that all authors take the time to learn this formal language and then use it.
It's worse than that.
The "formality" of a formal language is only in the syntax. Semantically, all languages are informal. Even within a nominally formal field like physics the way individual physicists ascribe meaning to the formalism is radically different. This happens even when doing "normal science", and is much worse when something radical like the language of dynamics is changing the way it did in the early 20th century.
A friend who works with GIS systems in geology puts it this way: "I can send a team out to map an area using a common ontology, and at the end of the day when I bring all their data together I can determine who mapped where, but not what anyone mapped." What simple geological terms like "granite" mean vary sufficiently between individuals that different people will ascribe different boundaries to "the same" structures.
The deep problem here is that all boundaries are fundamentally epistemic in origin--metaphysically the world is a complex soup that can be chopped up in an infinite number of self-consistent ways. Some of those ways are more useful to creatures like us than others, and science is a process of figuring out consistent and useful boundaries. So the very notion of a static ontology is therefore of limited utility--not useless by any means, but prima facie limited to relatively small slices of reality over relatively short periods of time.
The second rule of the Internet Dating Club is that EVERYBODY lies.
The third rule of the Internet Dating Club is that if it's your first date, you MUST confess. Besides, at that point it becomes obvious that you really have more years, more weight, less hair and fewer teeth than you claimed online.
As near as I can tell from my own experiences and the tales told by the women I've met online, dishonesty is about equally distributed between men and women. The sites with the highest level of honesty are the free ones like plentyoffish.com and okcupid.com. I'm not sure why this is--maybe because the people there have less invested in the whole process and realize that the net is a great way to make contact and and a lousy way to get to know anyone.
You can't solve every problem with a hammer.
But you can solve every problem with a chainsaw...
If you really want to scare someone from 1920, put him in a car and hit the expressway. They'd faint dead away.
Yeah, I was just thinking about a comment my father (born in 1921) once made, that when he was kid it was a commonplace to believe that high speeds alone could have deadly effect. He knew people who literally believed that when someone fell from a height they were dead before they hit the ground, killed by the speed of their fall.
Despite the fact that trains had exceeded 100 MPH in the late 1800's, and aircraft were going much fast than that by the end of the '20's, speed was still an exotic experience. The idea of people routinely going at 65 MPH or more in dense traffic would just amaze a time traveller from that era, far more than cell phones or holding cameras oddly.
Commonplace female executives and other professionals, particularly female doctors treating male patients, would shock our imagined traveller. Fowler makes an impassioned plea for the use of feminine professional terms like "doctoress" and "lawyeress" in, I think, The King's English, because although he could imagine intellectually that women might enter those professions in larger numbers in the future he could not imagine that they would ultimately be treated just like any other member of those professions.
Universal mixed-race teams in professional sports would be shocking, as would universal mixed-race schooling. The civil rights movement really did change things.
The ubiquity of bare skin would be another shock. I was walking by a public park the other day and blissfully noted a couple of young women sunbathing in bikinis that might between them be sewn together into something the size of an ordinary handkerchief.
The most shocking thing of all, though, would be that we went to the Moon half a dozen times and then just stopped.
the dark matter
/. is to encourage people--especially astonomers--to stop talking about "the" dark matter. There are several different dark matter problems, and they may well have quite different solutions, some of them a lot more exotic than others. Galactic dark matter is (at least potentially) baryonic. Dark matter on larger scales is almost certainly not baryonic unless we've really goofed on the whole primordial nucleosynthesis thing.
One of my minor crusades on
The discovery of these small objects suggests that the initial mass function could have a much stronger low-mass tail than anyone thinks plausible, so despite the MACHO results there is still a chance for a baryonic solution to the galactic dark matter problem.
Companies don't want people who can get the work done, they want people who can get the work done professionally.
No, they want people who can make managers feel good.
Doing a good, professional job is well down the list of things that companies want. Far more important are things like: does not make their manager feel stupid, even when the manager makes stupid suggestions; does good work in such a way that their manager can take credit for it; does not point out stupid management decisions to management's face; does not point out how poor policy decisions have created a situation that is now being solved by implementing even worse policy decisions because they waste resources on short-term band-aid solutions rather than invest resources in longer-term corrective action; and so on.
Young kids don't have the political savvy to realize this, and therefore are only hired in boom times. Besides, managing young kids doesn't give managers anything like the ego-boost that managers get out of older people. There's nothing a semi-competent MBA with adequacy issues loves more than managing people who are smarter, more technically capable and older than their manager.
When I read the New Testament, one thing that really stands out to me is the emphasis Jesus placed on always asking questions. He never told his followers to obey him obediently. He wanted them to question his actions and words.
You must be reading a different New Testament from the rest of us. For example, Christ's pronouncements on divorce look nothing like your description above.
Mark 10:2-12: "And the Pharisees came to him, and asked him, Is it lawful for a man to put away his wife? tempting him. And he answered and said unto them, What did Moses command you? And they said, Moses suffered to write a bill of divorcement, and to put her away. And Jesus answered and said unto them, For the hardness of your heart he wrote you this precept. But from the beginning of the creation God made them male and female. For this cause shall a man leave his father and mother, and cleave to his wife; And they twain shall be one flesh: so then they are no more twain, but one flesh. What therefore God hath joined together, let not man put asunder. And in the house his disciples asked him again of the same matter. And he saith unto them, Whosoever shall put away his wife, and marry another, committeth adultery against her. And if a woman shall put away her husband, and be married to another, she committeth adultery."
There is no questioning nor observation nor experiment here. There is a bald pronouncement: divorce is forbidden (there is a hotly contested description of the same exchange in Matthew that may permit divorce on some grounds if we could only figure out how to translate the Greek word "pornei" unambiguously.)
The key to this passage is the question of scriptural authority vs the authority of Christ. Jesus is saying that even though the scriptures permit divorce, God doesn't approve of it and the time has come to end it. Jesus is claiming arbitrarily and without a shred of empirical evidence that God wants married people to stay that way. Period. He does not mention social ills or practical problems. He simply invokes what God wants. This why Christianity is religion, not science.
There is no practical way within the Christian framework to challenge Jesus' flat-out prohibition on divorce. To do so you either have to avail yourself of Matthew's ambiguous loophole, or you have to deny the validity of Christ's words in this instance, possibly invoking the fact that we know prohibiting divorce can lead to various social ills, the exploitation and/or battering of spouses, etc, and Jesus was clearly against that kind of thing.
But once you have done that you are well on your way down the interpretive slippery slope that leads to secular humanism. You'll find lots of friendly people ready to greet you with open arms when you reach the bottom!
I was skeptical then, I'm skeptical now. Tools like the ones described are useful, but they're not foolproof, and they hardly supplant the intuition and "art" that is programming.
I once studied "Z", a specification language that was supposed to eventually be able to feed automatic correctness checkers. I realized how bad the language was when one of the canonical examples required that the design of the code itself be contaminated by the constraints of the specification language.
For some very narrowly defined problem domains I'm sure tools like this are useful, but I'm equally sure that the specification of a useful, general-purpose tool of this type would grow in complexity until it finally collapsed under its own weight. The final specification of an effective design evaluation tool would read, "Entity with intelligence, understanding, taste and good judgement."
automatic code generation is even more of a joke (at absolute best, it saves you 5 minutesof typing boilerplate class skeletons).
False.
I have written a series of XML-based code-generators over the past five or six years, and found them increasingly useful. I started out with a big dream: represent an application as a narrative and tie the document structure (DTD) to the program structure in a deep and powerful way.
Like a lot of big dreams, it didn't survive contact with reality (or with other developers). After seeing the framework gutted in a re-write by a developer who needed to "simplify" it to understand it, I re-wrote it for my own use without such grand ambitions but with a lot more practicality.
Propertly done, generated code gives you a lot more than a five-minute savings. It gives you all of your serialization code, which I particularly hate writing, and it gives you some access to a higher-level modelling language. Admittedly XML is not exactly god's gift to data modelling, but it's better than nothing (I actually tried developing an implementation of the code-generator in XSLT, but have subsequently decided that I'd rather chew my own leg off than go there.)
I treat the code generator like a particularly intelligent junior developer--one who is capable of understanding my design and writing code that implements that design and conforms to my company's coding standards and serializes the classes to well-formed XML. This kind of thing is also useful for prototyping, and useful for exploring the conceptual aspects of the design. I will often rev the XML specifications quite a few times before generating any code, simply in the process of getting the representations and relationships right.
A well-written code generator is a valuable tool in any developer's toolkit. Mine is not yet ready for prime time (no documentation to speak of, and I'm too busy with clients right now to write any) but I'm sure there are others out there that are just as good.
I'm a Canadian working in the U.S. on a TN visa. My I-94 has a chip. Big deal. I can always wrap it in foil if I don't want to be tracked inside the U.S., and it's a convenience crossing the border because by the time I talk to the guy in the booth they know who I am and what I'm doing there.
Chips in documents are unobtrusive and innocuous, because you can always shield them.
Chips in people are violations of certain inalienable rights, and if the U.S. were ever to go forward with this programme it would be an isolationists dream. The only people entering the country would be either illegal or desperate. No one with any opportunity to avoid it would ever go near the U.S. again.
And on this point, I agree: if I buy a security product that claims "secure file storage", and I find out that they implement this single-DES encryption -- and espeicially if my data is compromised as a result -- the vendor should be liable. They made a false claim!
While I agree that single-DES is not very secure, it is more secure than no encryption at all and therefore may warrant being called "secure". Without a truly vast and Byzantine body of law to define what various words mean, such claims are without value.
In other areas where product liability is at issue there are two solutions: government mandated standards and inspections, and the aforesaid vast and Byzantine body of law. These have given us "USDA Grade A" and "Made with REAL FRUIT" labelling, respectively.
I personally think it's about a decade too soon for this kind of thing in a field as fluid and poorly categorized as software, and it always will be.
Is it that the border/immigration laws themselves are unpalatable? If so they should be changed.
The problem is that border/immigration laws will not make America substantially more secure because any point-of-entry security protocol is bound to be porous, and once inside the barrier there is no practical way of identifying illegal immigrants. Bush's laughable proposal of "tamperproof IDs for immigrants" neglects to account for the fact that immigrants are perfectly capable of faking citizen's IDs. Instituting universal, biometric IDs for citizens is a much, much harder political sell than for immigrants, so it is likely that most illegal immigrants will get fake citzen's IDs of one kind or another.
Furthermore, focusing on the border as if a wall could keep THEM out tends to make the whole security issue one of US vs THEM, which is silly. Timothy McVeigh was an American. The London bombers were Britons. Fighting terrorism is not primarily about securing borders. It is primarily about good police-work within healthy, supportive, open communities. Building walls and demonizing illegal immigrants does not further those ends.
To put my point about border security in geek-friendly terms, when building a secure, robust system there are two ways of dealing with pre-condition checking. The first is to do a one-time check at the entry of a block where a condition is required, and then let everything within that block proceed on the assumption that the condition has been met. The other is to check the condition immediately before it gets used, every single time.
The former is less resource-intensive, but the latter is the only way to be sure. For example, I've seen code that does something like this:
if (0 != pFoo)
{
someMethod(pFoo);
}
else
{
throw NullFooException();
}
and someMethod() merrily dereferences pFoo without checking it because the developer "knows" it has already been checked. But of course at some future date some poor maintenance coder will call someMethod() from somewhere else without checking, and things will blow up.
For real robustness (and real security) defense-in-depth is required. But in human societies that means a police state, which is far more dangerous to the life and liberties of citizens than the threats they are intended to counter. Remember--terrorism kills fewer people each year in the United States than falling down, suicide or HIV (in most years it is vastly fewer, but fewer even in 2001).
Stephen Flowers' "Software Failure: Management Failure" is a must-read for anyone who is serious about software development. Based on about ten case studies, mostly of large IT projects, he identifies a set of factors that are strong failure indicators. In my experience the factors apply to non-IT projects as well, like ordinary desktop application development.