A mentality of "it will be done when it's right" is almost as foolish as "it will be done on Thursday." Software will never be "right". Quality software requires people who are able to perform proper risk management during all stages of development. I will not prevent my team from moving from discovery to design just because I think there may be requirements we are missing (hint: there always will be). We will move on when I believe the risks of moving on are less than the risks of not moving on.

My current backlog is full of feature requests, suggestions for more clear UIs, bug fix requests, etc. If I waited for my backlog to be clear before each release, my boss would still be waiting for our alpha version. Part of my job is also making business users comfortable with my change management decisions. If my bosses implore me to finish testing too early or slack on documentation, it is largely my fault for not convincing them it is a bad idea.

70% failure rate really doesn't seem high at all compared to various failure rate studies I have read. Here is a study which shows 68% of all IT projects fail, so I guess an extra 2% for distributed teams isn't too bad.

One problem of these failure rate studies is how you measure failure. Most of them lump into one group all projects which exceed their budget, fail to fulfill the full project scope, or other common scenarios. It may seem reasonable at first, but is a one year project that goes live in thirteen months really a failure? Or if the management team carefully removes some features from the scope so it doesn't go over budget, is that still a failure? Sometime yes and sometimes no on both accounts.

The most important thing to remember is these studies are being marketed to companies who sell requirements gathering tools and consulting services, so they should be taken with a grain of salt. For instance, the company who did the study I linked to above has the following paragraph at the top of its mission. I hope it puts into perspective any doom and gloom predictions made about how likely a project is to fail if you don't use proper enterprise-wide requirements solutions.

This just sounds like a problem which can be solved by opening up research to the search industry instead of behind paywalls. I have used IEEE and ACM recently and find their searching capabilities to be horrible. Give a company like Google full access to all research papers by both organizations and research productivity would be greatly increased.

They do generally have guidelines of what will be included on the tests, which is what they use when "teaching to the test." Some examples include the curriculum frameworks given for the AP exams. I concede that more breadth in testing questions wouldn't help stop schools from becoming a more Korean-like rote memorization environment, but I didn't really plan on giving a 50 page dissertation about every detail of developing national tests in a Slashdot post.

There are tests developed to measure things like critical thinking and problem solving. PISA is one example. The more data we acquire the better we can measure skills with multiple choice and short answer questions, instead of more labor intensive and very unreliable intuition based criteria.

Increased testing does not have to mean increased rote memorization. It is yet another strawman argument used by those who feel there are parts of our education system that are beyond improvement.

And BTW, don't be an asshole.

Unless you know of a few dozen of your fellow inmates who also pull in 6 digit salaries, I think you are a bit of a rare success story. That is great, and rare success stories do happen. For instance I flunked out of college, worked as a shift supervisor at a fast food restaurant until I was 24, and still crossed the $100k barrier as a software developer by the age of 32. But I sure wouldn't advise average college drop outs that they are likely to have the same lucky success I did. For instance there were also many things working in my favor: been programming since I was 8, above average intelligence even among college graduates, a supportive family as a safety net while I was failing in life, etc. Something tells me you were an above average convict as well.

They can already do this now with foreign labor. And they can already hire 4 low quality recent college grads for the same price as well. But they don't, because they don't want to deal with a large team of people causing their bosses more headaches than they are worth. They don't want to deal with inaccurate data on their corporate reports, support cases which are orphaned in the database, or business users who refuse to use their new CRM/ERP systems since it is too buggy to be useful. They want someone who fixes problems, not people who create them.

Many pointy hair bosses aren't smart enough to realize the value of quality employees, but enough of them are.

The same way I compete with developers with little to no college debt today (median student loan debt is still only around $10k), and who live in the cheap neighborhoods near me instead of the high property value township I live in. By being better than they are.

... and won't pass any corporate background checks. I think it is great to teach inmates anything that could help them lead a productive life after prison. But personally I would start with professions where background checks are not common.

It seems improbable for people with few job skills to come out of prison to get $50k/yr jobs as developers. I would be happier if prisons spent times training inmates for more realistic jobs where they may only make $18/hr, but will actually have a chance of being employed.

If we are going to spend this much on tests, I wish we could actually get some tests worth this kind of money. Create a test with 100,000 questions, but with only a hundred or so given to each individual student. For a school with 100 3rd graders, you would only give 10% of the total questions to this school. This way there could be no "teaching to the test" because the material on the test is too vast. And you don't have to worry about students cheating. Teachers would simply have to teach the way they used to, but with tools helping them find areas of improvement.

With enough of these tests given out, you could produce statistically significant metrics. Tests could also continuously evolve if they find the results are not a good predictor of actual knowledge. Current standardized testing has been found to be a very poor predictor, but probably only because the statistics used to measure and create the tests are so poor. We should not only say a history class is scoring in the bottom 20% on the civil war, but also that there is a 60% chance they could really be in the top 50% because the sample size of questions / students were too small.

If you go another step further and have teachers record data on what general information was covered each week, the algorithms could make great use of this data. The results could take into account that it has been 5 months since you covered the civil war. Now you would be measuring long term retention instead. The algorithms could even give scientifically studied recommendations on what material to cover to provide a better breadth of knowledge for the students.

For this kind of money, we should be getting tools that actually help in teaching instead of just those used in a perverse blame game.

What are you talking about? If I share a pizza with a friend, we are both probably going to chip in for the cost. I may even pay a little more than 50% if my friend picked it up, since he put in more effort than I did. That is no different than sharing my car with someone and them paying me back for my gas, maintenance, capital costs, and my time.

The Lyft driver is not a cab driver in the same way my friend is not a pizza delivery man for picking up the pizza. Now when you have people buying a car specifically to pick up Lyft users and considers those fees a significant portion of his income, then they start to blur the lines between sharing and just being a business.

Because the stadiums, concerts, etc. still couldn't charge a 5x markup when the alcohol is sold at the venue.

This is usually just a management issue. Any company with enough developers where you would even contemplate firing 50% at once is going to have a large number of poor quality developers. A company with bad management will allow these developers to drag the productivity of the good programmers down. A company with good management will find uses for them.

I find bad developers are still very good at doing a large number of boring and labor intensive tasks. Manual test validation comes to mind, but there are plenty of others. Having competent senior level developers also helps create an infrastructure within your code base that is more forgiving of bad developers. I have many common development tasks templated well enough that anyone who knows even basic coding can be productive. And with guidance those poor quality developers may get better. I consider most of the work I did 10 years ago to be pretty poor by my current standards.

Humble but poor quality developers are incredibly useful and almost necessary in most development teams. Without them you will be giving your senior developers too much busywork. Its arrogant and poor quality developers who need to be fired as soon as they are identified.

Okay, I should have said "In a court of law". Someone summarily executed by someone after conferring with other witnesses right after the event happened knew with 100% certainty in some situations. But as soon as it goes to court the probability lessens.

A jurist needs to weigh the possibility of inaccurate memory, a massive conspiracy, etc. They may still be effectively 100% sure of guilt, but still not truly 100% sure.

Well, I contend that you are morally obliged to comply and assist in both situations, but concede my moral viewpoint is not universally held. I didn't know that not reporting a crime was a crime though, although since I would have already felt morally obliged I guess it wouldn't have affected me.

First off you are crossing back and forth between not liking circumstantial evidence and not liking the accuracy of DNA evidence. Even if DNA evidence was 100% effective, you still have the issue of circumstantial evidence tying them to the actual murder (instead of just to the knife). And if you have eyewitness or clear video footage you may not have to rely on circumstantial evidence, but you do have to deal with the same accuracy problems of DNA. Even the most high resolution video camera probably has far less reliability than DNA. Perhaps they just look like the murderer, just like their DNA could look like the murderer's DNA.

The problem is not circumstantial evidence or inaccurate evidence. The problem is not enough evidence. Placing the suspect's DNA at the scene may only make you 99.8% guilty, which potentially means about 14 million people on Earth look as guilty as you. But placing you in the same neighborhood during the weekend the murder took place may bring that number down to 20 people. I would be fine with the police questioning all 20 of those people if they couldn't narrow the search more.

People need to understand that no one has ever been convicted with 100% certainty in the history of history. Perhaps with 99.999999999999999% certainty, but not 100%. Even evidence that is only 2% accurate is useful when combined with a large amount of other evidence (like being in the same neighborhood as the victim, which is probably closer to 0.01% accurate by itself).

As our society's data crunching abilities grow, we may start to create more quantitative estimates of guilt. We could set a threshold of guilt that has an acceptable amount of false convictions. Say 1 false conviction in 10,000 accurate convictions. Regardless of any delusional ideas that our justice system is set up to never convict innocent people, we will always need to leave room for doubt. That is why we say "beyond a reasonable doubt" instead of "beyond any doubt".