Money is a great demotivater. You certainly can demotivate someone who is passionate about a job by underpaying them - even just a little bit of underpaying can be disastrous.
However, money is not a great motivator for people passionate about a trade or skill except, perhaps, in special circumstances where that trade or skill is money oriented (banking/finance for example). In fact, trying to motivate someone by significantly overpaying them can backfire because they may become fearful of losing their job and returning to "market rate" and having $50K less a year to spend/invest. In a field like software development, you don't want your employees to be too motivated to "keep their jobs", you want them to be very motivated to "do their jobs" well -- and sometimes that means telling the project manager that "Nope, we can't/shouldn't do X in time Y because if we try, it will suck" or telling their manager "The weekly Aggregated Project Control Summary Assessment Review Status Inventory Process is taking me two hours a week to complete and I think it's a complete waste of time - please explain why this is of benefit".
Most great developers I know would work for free if their modest needs were provided for and they could do what they love to do. Of course, what one developer loves is different than what the developer in the next office loves. It's the responsibility of management to figure that out and assign work/guide the project to best "exploit" (in a positive sense) the strengths/weaknesses and passions of each developer while also giving them assignments that allow them/urge them/require them to expand their scope and horizon -- esp. for less experienced developers who are more likely to benefit.
Perhaps he had trouble finding an open source spell checker he could freeload off of without contributing in some way (and, seriously, would you want him contributing to the dictionary component of a spell checker anyway given your view of his unassisted spelling skills?).
The exception for "small batch manufacturers" bemuses me. A small manufacturer, by nature of their size, is much less likely to be able to control their materials, have staff that understands science behind various risks and how to test for them, and have the facilities for proper testing of their raw materials and finished product. The large manufacturers are also more able to compensate for damages their products may cause.
Why should some kids not be protected just because their parents decide to buy toys from "boutique" manufacturers?
If there were 100,000 small manufacturers who provided toys to ½ of the kids and 1 large manufacturer who provided toys to the other ½ of the kids, it seems that the manufacturers to watch more closely are the 100,000 small ones. The large one has the resources to watch themselves and a strong motivation to not sully their brand name (billions of dollars is at stake for them, vs. just declaring corporate bankruptcy at the first hint of a lawsuit and starting a new business with a different name the next week).
It makes one wonder if some safety regulations are motivated more by the desire to "level the playing field" by putting hurdles in front of large businesses.
(Same logic applies to all farming, ranching, and food production rules which require lower level of compliance/checking for small vendors).
I've developed in systems where a single data corruption problem that wasn't caught as such (for example, a triple bit error in memory that wasn't detected, let alone corrected, by ECC) would bring down millions of dollars worth of hardware. That quickly got the unwelcome notice of CIOs, and sometimes CEOs, of some large companies. And, I thought that was the best answer as, in those systems, the data integrity was more important than uptime (and we got a nice, if enormous, core dump from all the processors to try and figure out what happened if it hadn't been a hardware error). Obviously a different approach is appropriate for a central telephone switch where loss of data on an individual call once every month is much less important than keeping the system up.
My main point about data corruption is, it's hard to detect much of it as being "data corruption" and hard to even test for most of it -- only redundancy allows you to detect it in most cases. You can put in hundreds of tests, each with the potential for its own bugs and with the potential to exclude what will, in the future, be a valid state and still miss most of it - SEGV is your friend in this case.
In many cases, the "data corruption" case is just impractical to test for very well unless every datum has a hash or something associated with it or another copy exists and every function verifies the hashes or for both copies matching on entry.
Also, I've seen code that was so filled with validation of stuff that was already validated or produced by code we wrote that the bugs were mostly in the validation code not the logic associated with the core functionality.
There is a happy medium. It's important that an appropriate point on the continuum is picked based on the type of task (such as controlling the engines on a commercial jetliner engine vs. making a smart recommendation on what other articles the viewer might want to look at on a news site) and the implementation environment (such as assembly vs. Java). It's also important the everyone on the team grok where that appropriate point is for the task.
I think in common usage, white box testing does not mean "debugging" or "diagnosing" the code - it means more like "testing that takes into account the internal design and implementation of the system under test rather than just the inputs and outputs".
There's a need for both types of testing. However, as long as white box testers don't get too wrapped up in the details to step back and view the system as a whole (as developers sometimes do), they can do both. But there are so few good testers in the business, you don't want to waste a good white box tester on developing black box tests.
Sadly, I suspect there are quite a few "average" developers out there who, had testing as a career been given more respect by the industry over the decades, would have been "great" white box testers. While there is significant overlap between the skills/personality attributes needed to be a great developer and those needed to be a great tester, there are a bunch of skills/personality attributes that are quite important in one field and not nearly as so in the other.
A great quote attributed to Thomas Jefferson is appropriate here:
I'm a great believer in luck, and I find the harder I work the more I have of it.
Success is usually a combination of good luck (timing/being the right place at the right time) and being prepared/willing to take advantage of that luck. Almost everyone is the right place at the right time many times in their life -- but they miss most of those opportunities because they are not prepared or willing to take the risk that exploiting "luck" usually requires.
Interestingly, the closer to "middle class" you are, the greater the cost of taking a risk. If you're nearly penniless, you have little to lose and if you're rich, you can afford to lose a lot (and partition your assets so you keep perhaps $10M or so safe at all times).
If they check history carefully, they will find that in prehistoric times the people living there wanted a tunnel and began to bore it from the other end before money ran out. Bertha is just running into the front end of Big Bertha and they are butting (spinning) heads.
The good news is that the tunnel will now be completed ahead of schedule and we will also learn more about the irresistible force paradox.
In California, they have a bunch of bonds allocated for building a HSR that will never happen - maybe with a slight of hand their legislators could redirect that to making Thorium reactors practical!
Why does it matter the source of annoyance? The impact is the same regardless of the motivation. To me, a crying baby is much worse than someone talking on their cell phone.
That said, if Airline A and Airline B had the same prices/schedules but A banned cell phone calls and B didn't, I'd fly A.
I don't have a cite as I looked it up a few years ago.
It is my understanding is that in the first 10 to 15 years after installation, the maintenance costs for underground service for power and telecommunications are lower than for above ground and after that, maintenance costs for above ground are lower. As well, outages for above ground are shorter than for underground (due to the ease of access). The outages are less frequent for underground forever (or, at least within their design lifetime), but repairing an outage for underground is much more expensive and takes longer. I suspect some of this is regional though - in an area with bad ice storms every ten or twenty years (wiping out a LOT of above ground infrastructure and probably little underground), the numbers may be different than in other areas.
But I never have understood the sanity behind jumping out of a perfectly good plane.:(
Given the condition of some of the jump planes I've jumped out of, jumping often seemed like a better option than landing with the plane - it probably wasn't statistically though. I've landed in small planes so few times (usually when the clouds were closing in and the pilot decided to abort the jump run before the hole in the clouds was gone as they were flying VFR) I always found it unnerving and felt much more comfortable landing under my canopy.
I think your 'entrapment' example is way beyond what is needed to qualify as entrapment.
A better example might be...
Entrapment: Undercover police officer approaches you on the street and offers to sell you a white powder. "You say no, I'm not interested". Police officer asks again, you say "No, I'm not interested, I don't use any drugs including cocaine - and it would be illegal for me to buy it anyway." and you walk away. The police officer follows you and tells you "Actually, this substance is psuedo cocaine and is perfectly legal, the government allows it because it lacks the negative health impacts even though it provides the same high as cocaine does. Here's a news report [fake of course] from AP that describes this substance and shows it's legal." You buy a bit of her product (which may really be cocaine) - judge throws out case after you spend $20K on lawyers.
In this example, the police officer enticed you to buy something that you clearly were not seeking and did so by lying about what you were buying. Actually, even my example is well into "entrapment" land -- the police officer following you and pestering you to buy might be enough after you had explicitly refused to buy her product multiple times.
Of course, different jurisdictions have different definitions of entrapment and have different standards as to who must prove it is/isn't entrapment.
Or, just fly your cars (multiple needed for backup and for security details) in your second 747. Poor folks may have to cram the cars into the cargo hold on their primary (and only) 747 -- but that's pretty low class and only trailer trash would consider it.
Clearly there is only one fix here, we need to ask congress to allow geostationary satellites at lower altitudes, AND to raise the speed limit on light. I can't believe they haven't addressed these issues!
Typical "big government" wasteful spending. All Congress has to do is increase the speed of light by 100x, then there would be no need to allow geostationary satellites at lower altitudes. I'll bet you were hoping to bid on the contract for lowering geostationary satellites to new lower altitudes - nice try, we are on to your scheme.
I assume it would be completely impractical with current technology due to the dilution and the number of different, and duplicated, samples to test. However, I don't see why it could not be practical some day with enough research and development.
For some time I've believed that as DNA analysis improves, becomes cheaper, and becomes more scalable, we will see governments locate missing people/wanted criminals with DNA collected from the sewer.
For a targeted search, I envision "robot" crawlers with DNA sampling/classification systems being deployed where multiple sewer lines enter the treatment plant. When one of them finds a trace of the targeted individual's DNA, all the robots consolidate and crawl "upstream" from that point to the next set(s) of branches. This process continues until one of the robots is sitting under the sewage pouring from a single house/apartment block.
Another strategy is to put detectors at all sewage treatment plants and look for signatures of wanted people from a nationwide list. Once a treatment plant identifies, perhaps with multiple high quality hits over a few days, a specific high value individual, the smaller and more targeted search with robots crawling upstream would begin to narrow down the exact location of the targeted person.
Of course, this will cause "individuals of interest" to move more often -- but every move increases the risk of them being caught so the objective might still be achieved if all it does is keep wanted individuals on the move.
The technology is not there yet (the concentration of a targeted individual's cells, such as those sloughed off from the intestinal walls, is so low, I don't think we can economically wade through all the other cells to run across the interesting one(s)). But, perhaps in thirty years...
I found this term strange when I started tutoring students in elementary and middle school as I had not heard it before. However, the students were familiar with the term and, even though I was unfamiliar with it, I didn't have to ask anyone what it meant as it was pretty obvious (albeit, initially, awkward). I don't think this term causes much, if any, damage as long as it's abandoned as the students become more mature and sophisticated and when terms such as "equation" become more accessible and necessary. Although, I'm somewhat concerned when I've seen it still applied at the 7th grade level.
You assign the kid to a "lower" math group or, hold the kid back a year if they are doing poorly in many subjects. There should always be a path to higher groups as well as a potential "demotion" to lower groups. In fact, one would expect a substantial number of kids to change groups in various subjects. Clearly some time needs to be set aside to mentor those who are doing well in lower groups to help them make the jump up to the more challenging group (as they would have "missed" some material that the more advanced kids would have been exposed to by being in the higher groups).
This demonstrates why problems should be tested by real kids before being released on the masses.
One, albeit simplistic, test is to determine if particular questions are more likely to be answered "incorrectly" by kids who did well on other questions than by kids who didn't do well on other questions. If the problem is supposed to be hard, smart/more mature kids should do better on it than other kids. If the problem has been made hard by unintended ambiguity, smarter/more mature kids are sometimes more likely to get it wrong as they try to make sense out of the chaos that they are more likely to detect.
Although it may be too complicated for first graders, the "test group" might also be asked to mark each question with "how sure are you that you got the right answer (certain, somewhat sure, quite unsure)" to detect when kids feel they had to assume facts not in evidence to try to answer the question.
Sort of like politics - simplistic people come up with simplistic answers because they often fail to see the underlying and more subtle issues.
The point is, what this question really tests is how well the student can reverse engineer what some lazy, incompetent, or stupid (or, perhaps all three) adult meant when they wrote this garbage question.
Unfortunately, the smartest kids are the most likely to notice that the cup (which, usually, is used to hold liquids) on the one hand seems to have fluid in it and there are discrete objects on the other hand (we don't see pennies or Oreos or whatever in the cup, just a line appearing to depict a liquid level) and, thus, be confused.
This problem presents dissimilar objects in a comparison context and in later grades, I would expect students to declare that "the units are mixed" or something like that and insist that the teacher eliminate the problem from scoring.
This problem is rather like asking "If the whole is six seconds and you have five grams, how many more grams do you need to make a whole?"
Actually, those who have worked in development of parallel and distributed systems can do pretty good job at making sure they can predict the reaction to 10,000,000 logins (part of this is, of course, designing the system to be predictable and to degrade gracefully under load). Of course, there were almost certainly never anywhere close to that many concurrent unfinished login attempts to this website anyway (eventually, the Administration will tell us what the load was -- the system design and review seems to be so bad that it will take them six weeks or more just to tell us how busy it was - amazing).
Predictions about the reaction to load are not, of course, 100% accurate because getting them close to that is just too expensive. However, stress testing is how you verify the predictions and then fix the system to meet requirements. Somehow that little step appears to have been missed as everyone in the Administration was, supposedly, completely surprised by the failure.
Little that I've read about the healthcare.gov problems suggests to me that the problems are substantially load related unless the design just didn't take into account the fact that it would have many users. If you have the infrastructure to handle the expected load, it takes a very small fraction of that to simulate a load in a case like this.
Although I agree with most of this, a couple of points...
Private sector projects are not immune from the same effects. The differences are that such projects are not as visible to the general public, the public (unlike the shareholders) doesn't really care or see the impact directly of most project failures in the private sector, and private sector projects are more likely to be canceled when they get into deep trouble rather than continue of their own inertia (partially because cancellation affects fewer people, partially because the CEO/BOD are empowered to cancel the projects unlike in some political situations such as the ACA).
I agree that many people at the working level on the healthcare.gov project have known things were in trouble, but probably not most. Worker bees and managers (esp. first level managers) can be amazingly optimistic as their little piece seems to pass "unit tests" (or will after "just a couple more fixes") and all other groups are reporting the same status (true or not). What is underestimated is the number and severity of problems, sometimes architectural and sometimes just difficult to find/isolate/fix coding bugs, that come up in integration and alpha/beta test (healthcare.gov appears, at best, to been alpha at launch).
I'm a bit skeptical that it will be all better by the end of November (of course, the claim is only something like it will "work for most people" which is a pretty weak claim). Transferring authority and bringing in new people to oversee the project (esp. those that may not have a lot of experience in enterprise software projects) may slow down rather than speed up the remedies in the short term -- hopefully there are just a few problems left.
(And I don't know why the Spanish version was delayed or if it is supposed to be there by the end of November. It's strange to delay the part of the system that caters to those that you hope will increasingly vote in support of your party in the future. Was the design so screwed up that the presentation language got mixed up with the execution/business rule code? There can't be all that much to translate and it should scale well - there are plenty of English to Spanish translators available. Something is strange here.)
it is very easy to confuse a, say, green or red light from said billboards with the real traffic light- so IMHO at least the red, green and orange leds should be regulated, especially on areas with traffic and traffic lights.
I live in an area where yellow sodium roadway lights were installed many years ago (partially for "light pollution" reasons) and this created a problem much worse than any discreet billboard that I've seen.
Unfortunately, the roadway lights were almost exactly the same color as the yellow street traffic signal lights and lined up pretty well with the signal lights. When you were driving down some major streets at night you would see long lines of yellow lights (which were roadway lights) with an occasional red or green light (which were signal lights) mixed in. The problem was that when you saw a green light ahead and it turned yellow while you had glanced elsewhere, it virtually disappeared and required scanning among the street lights looking for the now camouflaged (yellow) signal light when you returned your gaze to the direct line of travel. After moving to the area, it took me a while to learn to make a mental note of exactly where upcoming green lights were so, if I glanced away, I could check in a fixed location to see if it had turned yellow. After a while it became second nature and I didn't even think about it anymore, but there were a few "oh shit, where did that red light come from" situations before that - esp. when traffic was very light so no driver ahead was putting on their brakes and providing a visual cue of a yellow signal light with their brake lights. I tend to glance around a lot when I drive anticipating possible upcoming issues (pedestrians, cross traffic that might be ignoring their signals, animals, bicyclists, kids, etc) so maybe I was more impacted by this problem than some.
Lots of people had this complaint but I guess it didn't cause enough serious accidents to warrant changing the roadway lights. Many or most of these roadway lights have been replaced with white LEDs. I now find it much less stressful to drive these roads at night and only now realize how distracting focusing on "remember the green light locations" effort was. I'm quite a bit more aware of pedestrians on sidewalks and bicyclists and the like now (which seems like a good thing). Although, the replacement LED roadway lighting seem to create more sharply defined "islands of light" with seemingly darker areas between the lights which make it a little harder to see objects off the side of the road in the dark patches - I suspect this is a combination of a narrower focus of the LEDs coupled with how the eyes adjust to the color and intensity of the sodium vs. LED lighting.
Slashdot Mirror
I think you nailed it.
Money is a great demotivater. You certainly can demotivate someone who is passionate about a job by underpaying them - even just a little bit of underpaying can be disastrous.
However, money is not a great motivator for people passionate about a trade or skill except, perhaps, in special circumstances where that trade or skill is money oriented (banking/finance for example). In fact, trying to motivate someone by significantly overpaying them can backfire because they may become fearful of losing their job and returning to "market rate" and having $50K less a year to spend/invest. In a field like software development, you don't want your employees to be too motivated to "keep their jobs", you want them to be very motivated to "do their jobs" well -- and sometimes that means telling the project manager that "Nope, we can't/shouldn't do X in time Y because if we try, it will suck" or telling their manager "The weekly Aggregated Project Control Summary Assessment Review Status Inventory Process is taking me two hours a week to complete and I think it's a complete waste of time - please explain why this is of benefit".
Most great developers I know would work for free if their modest needs were provided for and they could do what they love to do. Of course, what one developer loves is different than what the developer in the next office loves. It's the responsibility of management to figure that out and assign work/guide the project to best "exploit" (in a positive sense) the strengths/weaknesses and passions of each developer while also giving them assignments that allow them/urge them/require them to expand their scope and horizon -- esp. for less experienced developers who are more likely to benefit.
Perhaps he had trouble finding an open source spell checker he could freeload off of without contributing in some way (and, seriously, would you want him contributing to the dictionary component of a spell checker anyway given your view of his unassisted spelling skills?).
The exception for "small batch manufacturers" bemuses me. A small manufacturer, by nature of their size, is much less likely to be able to control their materials, have staff that understands science behind various risks and how to test for them, and have the facilities for proper testing of their raw materials and finished product. The large manufacturers are also more able to compensate for damages their products may cause.
Why should some kids not be protected just because their parents decide to buy toys from "boutique" manufacturers?
If there were 100,000 small manufacturers who provided toys to ½ of the kids and 1 large manufacturer who provided toys to the other ½ of the kids, it seems that the manufacturers to watch more closely are the 100,000 small ones. The large one has the resources to watch themselves and a strong motivation to not sully their brand name (billions of dollars is at stake for them, vs. just declaring corporate bankruptcy at the first hint of a lawsuit and starting a new business with a different name the next week).
It makes one wonder if some safety regulations are motivated more by the desire to "level the playing field" by putting hurdles in front of large businesses.
(Same logic applies to all farming, ranching, and food production rules which require lower level of compliance/checking for small vendors).
When it's easily detectable, I agree.
I've developed in systems where a single data corruption problem that wasn't caught as such (for example, a triple bit error in memory that wasn't detected, let alone corrected, by ECC) would bring down millions of dollars worth of hardware. That quickly got the unwelcome notice of CIOs, and sometimes CEOs, of some large companies. And, I thought that was the best answer as, in those systems, the data integrity was more important than uptime (and we got a nice, if enormous, core dump from all the processors to try and figure out what happened if it hadn't been a hardware error). Obviously a different approach is appropriate for a central telephone switch where loss of data on an individual call once every month is much less important than keeping the system up.
My main point about data corruption is, it's hard to detect much of it as being "data corruption" and hard to even test for most of it -- only redundancy allows you to detect it in most cases. You can put in hundreds of tests, each with the potential for its own bugs and with the potential to exclude what will, in the future, be a valid state and still miss most of it - SEGV is your friend in this case.
In many cases, the "data corruption" case is just impractical to test for very well unless every datum has a hash or something associated with it or another copy exists and every function verifies the hashes or for both copies matching on entry.
Also, I've seen code that was so filled with validation of stuff that was already validated or produced by code we wrote that the bugs were mostly in the validation code not the logic associated with the core functionality.
There is a happy medium. It's important that an appropriate point on the continuum is picked based on the type of task (such as controlling the engines on a commercial jetliner engine vs. making a smart recommendation on what other articles the viewer might want to look at on a news site) and the implementation environment (such as assembly vs. Java). It's also important the everyone on the team grok where that appropriate point is for the task.
I think in common usage, white box testing does not mean "debugging" or "diagnosing" the code - it means more like "testing that takes into account the internal design and implementation of the system under test rather than just the inputs and outputs".
There's a need for both types of testing. However, as long as white box testers don't get too wrapped up in the details to step back and view the system as a whole (as developers sometimes do), they can do both. But there are so few good testers in the business, you don't want to waste a good white box tester on developing black box tests.
Sadly, I suspect there are quite a few "average" developers out there who, had testing as a career been given more respect by the industry over the decades, would have been "great" white box testers. While there is significant overlap between the skills/personality attributes needed to be a great developer and those needed to be a great tester, there are a bunch of skills/personality attributes that are quite important in one field and not nearly as so in the other.
A great quote attributed to Thomas Jefferson is appropriate here:
Success is usually a combination of good luck (timing/being the right place at the right time) and being prepared/willing to take advantage of that luck. Almost everyone is the right place at the right time many times in their life -- but they miss most of those opportunities because they are not prepared or willing to take the risk that exploiting "luck" usually requires.
Interestingly, the closer to "middle class" you are, the greater the cost of taking a risk. If you're nearly penniless, you have little to lose and if you're rich, you can afford to lose a lot (and partition your assets so you keep perhaps $10M or so safe at all times).
If they check history carefully, they will find that in prehistoric times the people living there wanted a tunnel and began to bore it from the other end before money ran out. Bertha is just running into the front end of Big Bertha and they are butting (spinning) heads.
The good news is that the tunnel will now be completed ahead of schedule and we will also learn more about the irresistible force paradox.
In California, they have a bunch of bonds allocated for building a HSR that will never happen - maybe with a slight of hand their legislators could redirect that to making Thorium reactors practical!
Why does it matter the source of annoyance? The impact is the same regardless of the motivation. To me, a crying baby is much worse than someone talking on their cell phone.
That said, if Airline A and Airline B had the same prices/schedules but A banned cell phone calls and B didn't, I'd fly A.
I don't have a cite as I looked it up a few years ago.
It is my understanding is that in the first 10 to 15 years after installation, the maintenance costs for underground service for power and telecommunications are lower than for above ground and after that, maintenance costs for above ground are lower. As well, outages for above ground are shorter than for underground (due to the ease of access). The outages are less frequent for underground forever (or, at least within their design lifetime), but repairing an outage for underground is much more expensive and takes longer. I suspect some of this is regional though - in an area with bad ice storms every ten or twenty years (wiping out a LOT of above ground infrastructure and probably little underground), the numbers may be different than in other areas.
I would have think they probably used a SIGKILL rather than SIGINT for this task.
Given the condition of some of the jump planes I've jumped out of, jumping often seemed like a better option than landing with the plane - it probably wasn't statistically though. I've landed in small planes so few times (usually when the clouds were closing in and the pilot decided to abort the jump run before the hole in the clouds was gone as they were flying VFR) I always found it unnerving and felt much more comfortable landing under my canopy.
I think your 'entrapment' example is way beyond what is needed to qualify as entrapment.
A better example might be...
Entrapment: Undercover police officer approaches you on the street and offers to sell you a white powder. "You say no, I'm not interested". Police officer asks again, you say "No, I'm not interested, I don't use any drugs including cocaine - and it would be illegal for me to buy it anyway." and you walk away. The police officer follows you and tells you "Actually, this substance is psuedo cocaine and is perfectly legal, the government allows it because it lacks the negative health impacts even though it provides the same high as cocaine does. Here's a news report [fake of course] from AP that describes this substance and shows it's legal." You buy a bit of her product (which may really be cocaine) - judge throws out case after you spend $20K on lawyers.
In this example, the police officer enticed you to buy something that you clearly were not seeking and did so by lying about what you were buying. Actually, even my example is well into "entrapment" land -- the police officer following you and pestering you to buy might be enough after you had explicitly refused to buy her product multiple times.
Of course, different jurisdictions have different definitions of entrapment and have different standards as to who must prove it is/isn't entrapment.
Or, just fly your cars (multiple needed for backup and for security details) in your second 747. Poor folks may have to cram the cars into the cargo hold on their primary (and only) 747 -- but that's pretty low class and only trailer trash would consider it.
Typical "big government" wasteful spending. All Congress has to do is increase the speed of light by 100x, then there would be no need to allow geostationary satellites at lower altitudes. I'll bet you were hoping to bid on the contract for lowering geostationary satellites to new lower altitudes - nice try, we are on to your scheme.
I assume it would be completely impractical with current technology due to the dilution and the number of different, and duplicated, samples to test. However, I don't see why it could not be practical some day with enough research and development.
For some time I've believed that as DNA analysis improves, becomes cheaper, and becomes more scalable, we will see governments locate missing people/wanted criminals with DNA collected from the sewer.
For a targeted search, I envision "robot" crawlers with DNA sampling/classification systems being deployed where multiple sewer lines enter the treatment plant. When one of them finds a trace of the targeted individual's DNA, all the robots consolidate and crawl "upstream" from that point to the next set(s) of branches. This process continues until one of the robots is sitting under the sewage pouring from a single house/apartment block.
Another strategy is to put detectors at all sewage treatment plants and look for signatures of wanted people from a nationwide list. Once a treatment plant identifies, perhaps with multiple high quality hits over a few days, a specific high value individual, the smaller and more targeted search with robots crawling upstream would begin to narrow down the exact location of the targeted person.
Of course, this will cause "individuals of interest" to move more often -- but every move increases the risk of them being caught so the objective might still be achieved if all it does is keep wanted individuals on the move.
The technology is not there yet (the concentration of a targeted individual's cells, such as those sloughed off from the intestinal walls, is so low, I don't think we can economically wade through all the other cells to run across the interesting one(s)). But, perhaps in thirty years...
I found this term strange when I started tutoring students in elementary and middle school as I had not heard it before. However, the students were familiar with the term and, even though I was unfamiliar with it, I didn't have to ask anyone what it meant as it was pretty obvious (albeit, initially, awkward). I don't think this term causes much, if any, damage as long as it's abandoned as the students become more mature and sophisticated and when terms such as "equation" become more accessible and necessary. Although, I'm somewhat concerned when I've seen it still applied at the 7th grade level.
You assign the kid to a "lower" math group or, hold the kid back a year if they are doing poorly in many subjects. There should always be a path to higher groups as well as a potential "demotion" to lower groups. In fact, one would expect a substantial number of kids to change groups in various subjects. Clearly some time needs to be set aside to mentor those who are doing well in lower groups to help them make the jump up to the more challenging group (as they would have "missed" some material that the more advanced kids would have been exposed to by being in the higher groups).
This demonstrates why problems should be tested by real kids before being released on the masses.
One, albeit simplistic, test is to determine if particular questions are more likely to be answered "incorrectly" by kids who did well on other questions than by kids who didn't do well on other questions. If the problem is supposed to be hard, smart/more mature kids should do better on it than other kids. If the problem has been made hard by unintended ambiguity, smarter/more mature kids are sometimes more likely to get it wrong as they try to make sense out of the chaos that they are more likely to detect.
Although it may be too complicated for first graders, the "test group" might also be asked to mark each question with "how sure are you that you got the right answer (certain, somewhat sure, quite unsure)" to detect when kids feel they had to assume facts not in evidence to try to answer the question.
Sort of like politics - simplistic people come up with simplistic answers because they often fail to see the underlying and more subtle issues.
The point is, what this question really tests is how well the student can reverse engineer what some lazy, incompetent, or stupid (or, perhaps all three) adult meant when they wrote this garbage question.
Unfortunately, the smartest kids are the most likely to notice that the cup (which, usually, is used to hold liquids) on the one hand seems to have fluid in it and there are discrete objects on the other hand (we don't see pennies or Oreos or whatever in the cup, just a line appearing to depict a liquid level) and, thus, be confused.
This problem presents dissimilar objects in a comparison context and in later grades, I would expect students to declare that "the units are mixed" or something like that and insist that the teacher eliminate the problem from scoring.
This problem is rather like asking "If the whole is six seconds and you have five grams, how many more grams do you need to make a whole?"
Actually, those who have worked in development of parallel and distributed systems can do pretty good job at making sure they can predict the reaction to 10,000,000 logins (part of this is, of course, designing the system to be predictable and to degrade gracefully under load). Of course, there were almost certainly never anywhere close to that many concurrent unfinished login attempts to this website anyway (eventually, the Administration will tell us what the load was -- the system design and review seems to be so bad that it will take them six weeks or more just to tell us how busy it was - amazing).
Predictions about the reaction to load are not, of course, 100% accurate because getting them close to that is just too expensive. However, stress testing is how you verify the predictions and then fix the system to meet requirements. Somehow that little step appears to have been missed as everyone in the Administration was, supposedly, completely surprised by the failure.
Little that I've read about the healthcare.gov problems suggests to me that the problems are substantially load related unless the design just didn't take into account the fact that it would have many users. If you have the infrastructure to handle the expected load, it takes a very small fraction of that to simulate a load in a case like this.
Although I agree with most of this, a couple of points...
Private sector projects are not immune from the same effects. The differences are that such projects are not as visible to the general public, the public (unlike the shareholders) doesn't really care or see the impact directly of most project failures in the private sector, and private sector projects are more likely to be canceled when they get into deep trouble rather than continue of their own inertia (partially because cancellation affects fewer people, partially because the CEO/BOD are empowered to cancel the projects unlike in some political situations such as the ACA).
I agree that many people at the working level on the healthcare.gov project have known things were in trouble, but probably not most. Worker bees and managers (esp. first level managers) can be amazingly optimistic as their little piece seems to pass "unit tests" (or will after "just a couple more fixes") and all other groups are reporting the same status (true or not). What is underestimated is the number and severity of problems, sometimes architectural and sometimes just difficult to find/isolate/fix coding bugs, that come up in integration and alpha/beta test (healthcare.gov appears, at best, to been alpha at launch).
I'm a bit skeptical that it will be all better by the end of November (of course, the claim is only something like it will "work for most people" which is a pretty weak claim). Transferring authority and bringing in new people to oversee the project (esp. those that may not have a lot of experience in enterprise software projects) may slow down rather than speed up the remedies in the short term -- hopefully there are just a few problems left.
(And I don't know why the Spanish version was delayed or if it is supposed to be there by the end of November. It's strange to delay the part of the system that caters to those that you hope will increasingly vote in support of your party in the future. Was the design so screwed up that the presentation language got mixed up with the execution/business rule code? There can't be all that much to translate and it should scale well - there are plenty of English to Spanish translators available. Something is strange here.)
I live in an area where yellow sodium roadway lights were installed many years ago (partially for "light pollution" reasons) and this created a problem much worse than any discreet billboard that I've seen.
Unfortunately, the roadway lights were almost exactly the same color as the yellow street traffic signal lights and lined up pretty well with the signal lights. When you were driving down some major streets at night you would see long lines of yellow lights (which were roadway lights) with an occasional red or green light (which were signal lights) mixed in. The problem was that when you saw a green light ahead and it turned yellow while you had glanced elsewhere, it virtually disappeared and required scanning among the street lights looking for the now camouflaged (yellow) signal light when you returned your gaze to the direct line of travel. After moving to the area, it took me a while to learn to make a mental note of exactly where upcoming green lights were so, if I glanced away, I could check in a fixed location to see if it had turned yellow. After a while it became second nature and I didn't even think about it anymore, but there were a few "oh shit, where did that red light come from" situations before that - esp. when traffic was very light so no driver ahead was putting on their brakes and providing a visual cue of a yellow signal light with their brake lights. I tend to glance around a lot when I drive anticipating possible upcoming issues (pedestrians, cross traffic that might be ignoring their signals, animals, bicyclists, kids, etc) so maybe I was more impacted by this problem than some.
Lots of people had this complaint but I guess it didn't cause enough serious accidents to warrant changing the roadway lights. Many or most of these roadway lights have been replaced with white LEDs. I now find it much less stressful to drive these roads at night and only now realize how distracting focusing on "remember the green light locations" effort was. I'm quite a bit more aware of pedestrians on sidewalks and bicyclists and the like now (which seems like a good thing). Although, the replacement LED roadway lighting seem to create more sharply defined "islands of light" with seemingly darker areas between the lights which make it a little harder to see objects off the side of the road in the dark patches - I suspect this is a combination of a narrower focus of the LEDs coupled with how the eyes adjust to the color and intensity of the sodium vs. LED lighting.