Not all contracts are on a per-hour basis. Take house building. Sometimes when a job takes longer than planned, the contracting party is out of pocket. Sometimes the contracted party is out of pocket. That all depends what the contract says. Every party involved in a contract has to consider the balance of risk to reward when negotiating the price.

Quite. The OP isn't clear on this -- he seems to be assuming that the spec precludes interactions, but if he's got no way of proving that the failure to integrate isn't a failure of the spec, he might be leaving himself open to litigation if he doesn't pay.

I think the OP should perhaps be looking at insourcing the testing component, and testing to spec. Contractors can be expected to produce to spec, and the company should then be responsible for any problems that aren't caught by their tests against the spec, barring exceptional (and very clear) circumstances.

Who says he isn't factoring that into pricing? If I was PMing a bunch of contractors and there was a clause in my contract that transferred bug risk to the developers, I would fully expect the contractor rates to be higher than if I assumed the risk.

And if I was contacted by a PM looking to contract me with a "bugs at dev's expense" clause, sure as hell I'd ask more money for it.

This sort of risk/reward management is totally par for the course with any sort of contract management, and there are several solutions that are all fair and equitable (subject to negotiation and the informed consent of both parties), so there's no need to go ragging on someone who chooses a different model from your chosen one.

I was a programmer once, and I've recently returned to coding to attempt to produce educational software. My bugs are my responsibility, and when I eventually get to the point where I can sell the software to end users, they will remain my responsibility. My bug rate (currently very high, because I'm out of practice) will ultimately become a factor in my pricing strategy. A contractor is a supplier, not an employee, and should therefore be working to provide something to a contract. When I was at school, my parents hired a contractor to build an extension to the house. The project finished late, and the contract had penalty conditions for late completion, so my parents ended up paying less. This is standard practice in most contractor fields, so why should a coding contractor expect to be any different? Paying for bugs is effectively a bonus for late completion, which is a bit daft.

On the other hand, you do raise an important issue... does the OP actually hire dedicated testers or leave it to the devs? Leaving it to the devs is an invitation to a disaster.

No it's not. A contractor is not an employee, but a supplier. If Amazon sends me the wrong book, it's their mistake. They cover the costs of my return postage and them sending out the correct one. I do not pay directly for their mistake. Instead Amazon track the cost of their mistakes and factor it into their pricing. A contractor should be able to do the same: "OK, I generally make X bugs per 10000 LOC, so I'll need to have a contingency of Y days for this project..."

If your post wer so well ritten their wood bee know mis-takes in my response.

Do your job properly first time round. Done.

Seriously, aren't you upset when Microsoft sells you a new operating system and it's buggy? Didn't you pay for finished, working software rather than an extended beta test version? The whole software supply-chain would be much better managed if everyone was held properly accountable for their failure to produce code to the contracted specs.

Do you know this man, and do you know this to be true? As far as I'm concerned, I'll take him at his word that he is indeed talking about "bugs" in the sense of programming errors. The whole point of contracting is to shift risk, and if you're paid to write software that fits a spec and you don't, you've not fulfilled your contract. It's the contractor's responsibility to quote what he requires to get the job done to spec, and if his coding style results in an x% bug rate, that should be factored into his estimate.

This man's view of bugs is the right one, and it's a shame the industry (and the courts) don't have the same view. I'm sick of buying buggy software and being told it's "good enough" when it doesn't do what it promises.

Well here's a suggestion, then. Have students tick to self-certify "prerequisites", then have two pass rates, one for those who meet the prerequisites, one for those who don't.

But that same problem affects traditional education as well. The goal of any teaching should be to ensure that as many people as possible learn the material, but it's easier to ensure that people pass the exam instead. It's a downward trend that has been noted in schools and universities the world over.

The promise of MOOCs is to use massive data to improve the education, but it's an empty promise, because having thousands of people sit exactly the same course provides no useful data on what works and what doesn't. MOOCs are the slowest form of educational improvement in history, because what teacher doesn't revise his lesson every single time he teaches it -- that's an improved lesson for every 20 students in many cases....

Except it wouldn't: it would act as a "you're useless" call. The problem we have is not that students are "mediocre", it is that our teaching is massively suboptimal. Poor teaching turns people off learning. The challenge is for the teachers to improve in order to capture the students being failed by the system.

Unfortunately, this is extraordinarily difficult to do, and it also presents us teachers with the uncomfortable reality that we're not as good as we like to think we are. This leads us to protect our egos by dumbing down the exams rather than smartening up the exams. And most of us start out aware of this problem, but slowly convince ourselves we're doing a good job, and it's the students' fault....

...at which point you've completely destroyed the business case for each and every university. Why should I study with an expert in a niche field if he can't teach me about it because I have to pass a bunch of standardised questions chosen by a committee? The life would be dragged out of university teaching much as it has been out of school teaching.

What you are proposing is not university, and to those of you who don't like university, I say this: instead of trying to appropriate the term "university" and apply it to vocational education, why don't you simply work to raise the prestige of vocational institutions? In many countries in Europe, this is already in process (the UK recognises vocational college qualifications as being of equivalent level to university courses; France has "engineering schools", "technically university institutes" and "grand écoles"), with the Bologna Process also working to recognise technical qualifications across the EU.

Surely having high standards in teaching means making yourself a better teacher, naturally resulting in a high completion rate and pass rate? Low completion rate means there's gaps in your teaching. Yes, there's gaps in everybody's teaching, and it's our job to fill the gaps...

That said, you're correct about the problem of "admissions policy" -- Coursera has no model for course progression, and "open access" doesn't need to mean "access to everything", but rather "access to everything at your level"....

You have inadvertently highlighted one of the weaknesses of MOOCs: the tight time-bound nature of them. When I get a whim to learn something, I sign up to a Coursera module... but it's not starting for another 8 months. I see 5 courses I like... but they all start the same week. With thousands of people signing up for each, why don't we have a choice of start dates? Why not assemble cohorts of just (!) a few hundred and let each module run once or twice a month? I can't imagine this degrading the quality of the course in any way.

If you argue that not an algorithm is a mathematical process description, then we have a rather weird distinction. You're saying that business methods aren't algorithms, just processes. But any computerised version of that business process is an implementation of the process as a mathematical representation. Does that mean that a business process should be patentable in real life, but a computer implementation isn't covered by patent law because it's "math"? That would mean I can't get people to carry out your business process without a license, but I could get a computer to do it and not pay you a penny... which would work against economic growth. Or alternatively, perhaps the automation of a business process proves that it is mathematical at its core...?