Well said

So there is no such thing as a complete delivery then?

Well said.

This is indeed a worst case scenario, which unfortunately play out too often. It is most often caused by not having enough developers on the "His side" of the argument. I for instance am a senior level developer who is very involved in the business side of my employer's decisions. This probably comes from my time as a contractor where I have also seen these his side, her side, and the truth arguments play out time and again. A company that does not have enough developer minded people in CTO, VP of Software Development, Director of Application Architecture, etc. positions is going to find themselves in your worst case scenario quite often. Most well run companies I have worked for and contracted for have CS/EE majors with MBAs (or equivalently minded people) in the positions I listed above, so "His Side" in these companies have many of the best arguments from "Her Side" already included.

Technical debt is a necessity in any product. Being aware of this debt and estimating its impact going forward is very much a part of any quality change management process. Martin Fowler has a great blog post describing the relationship between prudent, reckless, deliberate, and inadvertent technical debt that is worth a read. I particularly like his reasoning behind the inadvertent / prudent quadrant.

If you don't take proper care of your technical debt, it will ruin any software product. But properly managing your technical debt is not the same thing as just taking "Her Side" every time she complains about technical debt.

There is rarely just one possible solution for any single bug. Change management processes are still involved even at this level of granularity. One solution may be to disable the feature causing the bug. One may be to provide a work around. One may be to put a quick "band-aid" on the code in question, and one may be to find and fix the root cause. If a bug needs to be fixed by Thursday, there are still options even if your developers can't figure out the root causes by then. Once again you weigh the risk of providing a quick fix now with the risk of providing a better fix after the deadline has past.

Honestly I feel your heart is in the right place, and your level of principles will produce far better products than those who care little for software quality. But your statements really don't reflect those of someone who has ever actually been in charge of large software projects. Either that or you are one who constantly feels things would have been done better if your bosses simply got out of your way. I could very well be wrong, but I doubt it. My guess would be you are a skilled senior level developer who likes to stay on the technical side of things, but that is mostly just a wild guess.

Code is not predestined to do anything. It does what humans have it do, either consciously or accidentally. If I say to release a product (with my bosses' approval), then the software is doing what it is supposed to do, which is go into production.

This is why I don't feel you are speaking from experience. The fact is getting those Christmas sales are probably far more important than your viewpoints on perfection. And sometimes those deadlines are there for a reason. Developers are not tasked with creating some shining example of what perfect code can be, they are tasked with making a return on investment. I have a project right now which is due at the end of April because it really has to be done by the end of April. The scope of the project has changed frequently as planning and development has taken place to ensure this April 30th deadline will be hit. And it will be hit. It will be hit without 80 hour weeks; it will be hit because proper project management techniques were used throughout the project. And part of those proper project management techniques are respecting that the deadline is there for a reason and there are very few requested features that are more important than this deadline.

Honestly, writing code is the least important and easiest job of a developer. We learn how to write code in the first few years of our career; probably in school. A quality software developer's career is spent learning the more important tasks of software engineering. This includes your senior developers knowing what can be done by Thursday. You can hit deadlines without just pretending your code is working. You hit deadlines by understanding the progress of the project and understanding the priority of its features at all times. This isn't some hobby or college assignment. There may be millions of dollars on the line, and thousands of employees or customers waiting.

I have worked in situations where some features were more important than the project's success. In safety critical situations there are times where you would rather have an entire project scrapped than product an un-safe product. Obtaining FDA approval, for instance, is the type of requirement which must be fulfilled. But these situations are rare; in most software development almost all features can have their priority level be put up for review.

These are all very real concerns for real world projects. These are exactly why project management is so important. You often cannot guarantee something will work, which is why you have plan B. The project I mentioned before has many aspects which we cannot guarantee success. As you mentioned, this is usually because of third party software we aren't experience in yet. But we have contingency plans for each of these risks. For one important risk we even have an employee developing the contingency plan just in case because it is that important. This plan B is missing many desired features, but we have enough experience to know it will absolutely work and can be done fairly quickly.

No one will ever guarantee 100% IT project success rates. But project success is not as rare as you make it out to be if things are done properly. Success does not always mean you get 100% of what stakeholders asked for and sometimes it does not even mean hitting a deadline. And I certainly do not mean by sticking to a motto such as "it will be done when it's right."

Success usually just means the stakeholders are happy with the result.

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.