I'm no longer responsible for the code I wrote once the customer has accepted it. Acceptance is based upon their testing. If they choose, they can pay for a sustainment contract which will guarantee my continued support. Other than that, they got what they paid for. Analogies don't work across different fields. There are best practices in every one, and at first glance, my take is that the OP is doing it wrong, but I'd need more details.
Again, that's all down to the specifics of the individual contract. And again, whenever there is a transferral of risk from one party to another, it's reasonable to expect the risk to be accompanied by additional reward.
Properly managed risk is a profit to the party assuming it -- the sum total of insurance premiums paid in a year is higher than the total of insurance payouts. A contractor (in any sphere) who assumes risk should increase his margins to ensure that in most foreseeable circumstances, he ends up getting paid more per hour than he would have got if he'd taken the work as T&M. The risk he's taking is on catastrophic problems... and as we're talking software development that would probably mean the developer being hit by a car, in which case getting paid nothing (because he's forced to hire someone else in to do the work while he's in traction) is the least of his worries. And besides, any contractor with any understanding of risk will have professional insurance to cover contracts incompleted due to personal injury or death anyway.
Moral of the story: the money's all in risk management.
When you talk about bug-free software, you sound like a manager, or at best, a sysadmin.
I prefer to think of myself as an "enlightened user". I don't want to be sold the latest bells and whistles. I don't want to be sold a new revolutionary version of Office that is faster for the untrained user to use, but slows things down for the power user. I don't want change for change's sake. I want to see software that lasts, and doesn't feed this constant replacement cycle when I'm still doing more or less the same crap I was doing ten years ago. Yes, my photos are bigger and have higher colour depth. But the sort of grunt my multicore, multimegahertz 64-bit machine has would have made the SFX team of Terminator 2 green with envy, and yet it still takes forever to insert a bloody gif into a word processing document!
Or quit your bitching and accept that you get a metric ass-ton of software with not-a-lot of bugs for less money than you spend on "designer coffee" in a week.
I'm not a coffee drinker, and I don't much appreciate your attitude, young man...
You said you were a programmer once. What made you leave the field?
Repetitive strain injury. A quick sideways move into desktop IT management saved me from the big old axe marked "redundancy". I'm heartily sick of desktop IT now though...
The other part when he/she talks about his/her client complains about bugs and he/she wants the developer to fix them for free. This is very important. What kind of "bugs" he/she is talking about? End users usually do not know what they want, and may expect something different from what the software introduces. As a result, the users complain and report the issue as a bug because it is not exactly what they want. If that is the case, the responsibility is for the OP himself/herself. However, if the bugs come from misinterpreting of the spec or incomplete implementations, it could be from the developer. I said it could be because there are some cases that the spec is not written clearly. This then refers back to what I said earlier, how excellent the spec writer the OP is?
And this raises the big question that I haven't seen raised elsewhere: does "I do not pay for bugs" mean "I do not pay to fix bugs" or "I do not pay to identify bugs"? This, I suspect, is where the real problem lies.
Manager: The client has reported a bug. Your problem — find it and fix it. Contractor: How do you know it's my problem? And are you sure it's even a bug."
Anyone running a per project contract needs to have a clause included about bug discovery/verification: the contractor should be safe in the knowledge that if he can provide evidence that the bug isn't his, he'll be paid for the time he spent investigating. Most professional software support contracts I dealt with had such a clause -- I could phone up their support line and if it was a bug, we wouldn't be charged; if it was user error, we'd be charged for the time spent investigating. If it was a change request, we'd receive an invoice for time investigating and a quote for the CR implementation. Some of the more generous companies would agree to waive the investigation time if we signed off on the CR....
A much better practice would be for him to pay for bugs, but be choosy on which developers he re-uses. In any other profession, the cost of "mistakes" are passed along to the customer. While building a new building, if the electrician installs a plug then realizes "oops, this is supposed to be a GFCI plug", it's not like he stops the clock, goes and gets a new plug, removes the old plug, installs the new one and restarts the clock. He gets paid for the cost of his "mistake".
I'm never hiring you as a contracts manager. His mistake, not mine: he pays. And that'll be in the contract. In fact, when my parents had an extension built on their house (as I related elsewhere), the contract included penalty clauses for late delivery. The building contractor paid the workers for the time, because it was his error, but he got less money from my parents on it. My Mum still reckons that the only reason the work got finished at all was that the guy was so far behind schedule that another week of delays would have meant he made a loss on the whole thing....
"A contractor is a supplier, not an employee, and should therefore be working to provide something to a contract."
Yes, a fixed amount of work for a defined period of time, this is why you pay them by the day or hour. If you want more than that then pay more than that. You don't get to pay a contractor for a days work then expect him to do a day and half's work.
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.
If I don't have complete control over the entire codebase, though, you can fucking forget trying to get me to fix bugs without being paid. Sure, I'll fix the odd one of mine that gets in, but I'm not going near problems caused by interactions with other developers' code unless I get paid.
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.
No it's not, and his predicament is proof of the fact.
He refuses to pay for bugs, which is an extreme way of attempting to encourage his developers to reduce bugs in their software. The fact he does this and still ends up with bugs shows that you simply can't avoid bugs, they're an inevitable consequence of any kind of complex work which software development is.
What he in fact needs to do is accept that bug fixing is an inevitable element of software development and he needs to pay for that so that the contractors will stick around and do it. He needs to factor it into his products and pricing, if he can't do that and remain profitable then his business plan isn't viable and he either needs to change it or go out of business and let someone who can do proper software development in a suitably profitable manner take his place in the market.
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.
Well, you should be paying them to fix bugs really... it's analogous to not paying a sports team if they lose.
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..."
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.
you can never trust someone to work for under market pricing - that's the problem he was having, moving risk of customers changing things and being under budgeted for the task to the contracted developer. that's why he spent essentially a paragraph praising himself.
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.
One of the concerns (which is often shared by the MOOC students themselves) is that the courses might become "watered down" so that more people will be able to pass them, but there will be less value in taking them. (If everyone wins in a lottery what's the point?)
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....
I'm being serious here: we're wasting valuable resources trying to keep mediocre people from entirely failing, only for them to get mediocre grades that barely give them their diploma so that they can go on to be mediocre employees with brains so numbed and dull that they're basically automata. If we let them fail (yes, letting people fail, the horror!) early on, it could act as a wake up call.
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....
Ideally, you separate the course from the final tests: students watch the lectures, do the homework for the course, but take a final competency test that is designed by a certification body, not the teacher of the class. It's a much better model for all involved: I waste a ton of my time and interview candidates' time seeing if they have basic skills I need: I'd love an off-the-shelf test for that combined with teachers trying to teach the skills required to pass that test. I'd pay real money to put a screening test online and have college professors respond by teaching to that test.
...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.
Although, I teach at a place with high standards and a high completion rate, but with a very selective admissions policy, I think that another good strategy is to have easy access and high standards, even at the cost of a high completion rate.
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"....
I am picking and choosing my courses based upon what I want to know so that I can put it to use tomorrow.
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.
C'mon not all processes are algorithms. Not all processes are implemented with MATH
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...?
I don't think that means what you think it means -- it's an artwork aimed at the learner. In music, there are "études" which take the theme of a larger piece as a vehicle for teaching, and students of brush painting often perform a "study" of an established artist's work in which they try to copy it in order to master their brush technique.
The first lens flare meme in filmed entertainment that I recall was in Babylon 5's CGI scenes, and we mocked that even though we loved the show and we weren't film students.
Whether this was intentional or not, lens flare served a rather useful function in early Babylon 5 episodes -- it subtley said "you are not here". Which is fair enough, because you're never going to be floating in space watching shuttles approaching a space station with your naked eye. Early Bablyon 5 was based on the station, and shots outside were establishing shots, or "meanwhile" shots of an incoming spacecraft presaging the latest crisis, or someone leaving, marking resolution. But the viewer, as an observer of the action, was rooted firmly on the space station. In Babylon 5, the action came to you (or at least in the first series or two... the series did lose something as it got older, was it a concidence that it lost momentum when the main characters started flying around in spaceships regularly?
So in a sense, JJ Abrams is being slightly daft and missing the point. By trying to create "immediacy" and "authenticity" by mimicking the look of fly-on-the-wall documentaries, he may in fact be losing it by removing the audience's illusion of being an actual fly on the wall.
The problem isn't people not liking the movie, it is people hating on it, often without even seeing it, because they feel like they SHOULDN'T like it. It is similar to the hipster attitude: Star Trek can't be good because it's popular and popular can't be good. The Onion had a hilariously spot on piece on the first one called "Trekkies Bash New Star Trek Film As 'Fun, Watchable'." There was plenty of that happening. Trekkies hating on it as being "not Star Trek" or getting mad because it was "mainstream" without any real criticism of the movie, just that it wasn't ok to like because of what it was.
I can respect anyone who says "I don't care for this," but doesn't hate on it, they just don't care for it because it doesn't match their taste.
Then let me give you a reasoned argument on behalf of those that just "hate on it": cognitive dissonance. Willful suspension of disbelief is central to all fiction. But contradiction of known "fact" (even fictional fact) breaks your ability to suspend disbelief. I once saw a film where this sicko had been raping children. But he'd already been castrated. Perhaps it is possible to maintain an erection after having your balls chopped off -- this is the sort of detail I would hope the writers would have checked with experts. And yet the truth or otherwise is irrelevant -- I could not immediately reconcile these things, and I was awoken from the illusion, and conscious of watching a film.
I am not a trekkie or a trekker or whatever, but I found it impossible to watch the first film. I could not accept the young Kirk as Kirk (heck, I couldn't accept him as someone who didn't just get expelled from the academy immediately) and assembling all the major characters from the series (including the not-even-in-series-one Chekov) was just far too improbable. For all I know it could have been one of the best written blockbusters of the era, but I would have been unable to see that because I was simply unable to accept the basic premise.
Yes, but this is a reboot of Slashdot. The original Slashdot included many episodes of informed debate focusing on human nature. In the rebooted franchise, there are goodies and baddies, and "-1 troll" means "you're wrong".
Slashdot Mirror
I'm no longer responsible for the code I wrote once the customer has accepted it. Acceptance is based upon their testing. If they choose, they can pay for a sustainment contract which will guarantee my continued support. Other than that, they got what they paid for. Analogies don't work across different fields. There are best practices in every one, and at first glance, my take is that the OP is doing it wrong, but I'd need more details.
Again, that's all down to the specifics of the individual contract. And again, whenever there is a transferral of risk from one party to another, it's reasonable to expect the risk to be accompanied by additional reward.
Properly managed risk is a profit to the party assuming it -- the sum total of insurance premiums paid in a year is higher than the total of insurance payouts. A contractor (in any sphere) who assumes risk should increase his margins to ensure that in most foreseeable circumstances, he ends up getting paid more per hour than he would have got if he'd taken the work as T&M. The risk he's taking is on catastrophic problems... and as we're talking software development that would probably mean the developer being hit by a car, in which case getting paid nothing (because he's forced to hire someone else in to do the work while he's in traction) is the least of his worries. And besides, any contractor with any understanding of risk will have professional insurance to cover contracts incompleted due to personal injury or death anyway.
Moral of the story: the money's all in risk management.
When you talk about bug-free software, you sound like a manager, or at best, a sysadmin.
I prefer to think of myself as an "enlightened user". I don't want to be sold the latest bells and whistles. I don't want to be sold a new revolutionary version of Office that is faster for the untrained user to use, but slows things down for the power user. I don't want change for change's sake. I want to see software that lasts, and doesn't feed this constant replacement cycle when I'm still doing more or less the same crap I was doing ten years ago. Yes, my photos are bigger and have higher colour depth. But the sort of grunt my multicore, multimegahertz 64-bit machine has would have made the SFX team of Terminator 2 green with envy, and yet it still takes forever to insert a bloody gif into a word processing document!
Or quit your bitching and accept that you get a metric ass-ton of software with not-a-lot of bugs for less money than you spend on "designer coffee" in a week.
I'm not a coffee drinker, and I don't much appreciate your attitude, young man...
You said you were a programmer once. What made you leave the field?
Repetitive strain injury. A quick sideways move into desktop IT management saved me from the big old axe marked "redundancy". I'm heartily sick of desktop IT now though...
The other part when he/she talks about his/her client complains about bugs and he/she wants the developer to fix them for free. This is very important. What kind of "bugs" he/she is talking about? End users usually do not know what they want, and may expect something different from what the software introduces. As a result, the users complain and report the issue as a bug because it is not exactly what they want. If that is the case, the responsibility is for the OP himself/herself. However, if the bugs come from misinterpreting of the spec or incomplete implementations, it could be from the developer. I said it could be because there are some cases that the spec is not written clearly. This then refers back to what I said earlier, how excellent the spec writer the OP is?
And this raises the big question that I haven't seen raised elsewhere: does "I do not pay for bugs" mean "I do not pay to fix bugs" or "I do not pay to identify bugs"? This, I suspect, is where the real problem lies.
Manager: The client has reported a bug. Your problem — find it and fix it.
Contractor: How do you know it's my problem? And are you sure it's even a bug."
Anyone running a per project contract needs to have a clause included about bug discovery/verification: the contractor should be safe in the knowledge that if he can provide evidence that the bug isn't his, he'll be paid for the time he spent investigating. Most professional software support contracts I dealt with had such a clause -- I could phone up their support line and if it was a bug, we wouldn't be charged; if it was user error, we'd be charged for the time spent investigating. If it was a change request, we'd receive an invoice for time investigating and a quote for the CR implementation. Some of the more generous companies would agree to waive the investigation time if we signed off on the CR....
A much better practice would be for him to pay for bugs, but be choosy on which developers he re-uses. In any other profession, the cost of "mistakes" are passed along to the customer. While building a new building, if the electrician installs a plug then realizes "oops, this is supposed to be a GFCI plug", it's not like he stops the clock, goes and gets a new plug, removes the old plug, installs the new one and restarts the clock. He gets paid for the cost of his "mistake".
I'm never hiring you as a contracts manager. His mistake, not mine: he pays. And that'll be in the contract. In fact, when my parents had an extension built on their house (as I related elsewhere), the contract included penalty clauses for late delivery. The building contractor paid the workers for the time, because it was his error, but he got less money from my parents on it. My Mum still reckons that the only reason the work got finished at all was that the guy was so far behind schedule that another week of delays would have meant he made a loss on the whole thing....
"A contractor is a supplier, not an employee, and should therefore be working to provide something to a contract."
Yes, a fixed amount of work for a defined period of time, this is why you pay them by the day or hour. If you want more than that then pay more than that. You don't get to pay a contractor for a days work then expect him to do a day and half's work.
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.
If I don't have complete control over the entire codebase, though, you can fucking forget trying to get me to fix bugs without being paid. Sure, I'll fix the odd one of mine that gets in, but I'm not going near problems caused by interactions with other developers' code unless I get paid.
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.
"This man's view of bugs is the right one"
No it's not, and his predicament is proof of the fact.
He refuses to pay for bugs, which is an extreme way of attempting to encourage his developers to reduce bugs in their software. The fact he does this and still ends up with bugs shows that you simply can't avoid bugs, they're an inevitable consequence of any kind of complex work which software development is.
What he in fact needs to do is accept that bug fixing is an inevitable element of software development and he needs to pay for that so that the contractors will stick around and do it. He needs to factor it into his products and pricing, if he can't do that and remain profitable then his business plan isn't viable and he either needs to change it or go out of business and let someone who can do proper software development in a suitably profitable manner take his place in the market.
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.
Well, you should be paying them to fix bugs really... it's analogous to not paying a sports team if they lose.
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..."
Oh shut the fuck up, if your specs were so masterfully created there would be no bugs.
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.
you can never trust someone to work for under market pricing - that's the problem he was having, moving risk of customers changing things and being under budgeted for the task to the contracted developer. that's why he spent essentially a paragraph praising himself.
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.
One of the concerns (which is often shared by the MOOC students themselves) is that the courses might become "watered down" so that more people will be able to pass them, but there will be less value in taking them. (If everyone wins in a lottery what's the point?)
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....
I'm being serious here: we're wasting valuable resources trying to keep mediocre people from entirely failing, only for them to get mediocre grades that barely give them their diploma so that they can go on to be mediocre employees with brains so numbed and dull that they're basically automata. If we let them fail (yes, letting people fail, the horror!) early on, it could act as a wake up call.
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....
Ideally, you separate the course from the final tests: students watch the lectures, do the homework for the course, but take a final competency test that is designed by a certification body, not the teacher of the class. It's a much better model for all involved: I waste a ton of my time and interview candidates' time seeing if they have basic skills I need: I'd love an off-the-shelf test for that combined with teachers trying to teach the skills required to pass that test. I'd pay real money to put a screening test online and have college professors respond by teaching to that test.
...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.
Although, I teach at a place with high standards and a high completion rate, but with a very selective admissions policy, I think that another good strategy is to have easy access and high standards, even at the cost of a high completion rate.
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"....
I am picking and choosing my courses based upon what I want to know so that I can put it to use tomorrow.
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.
C'mon not all processes are algorithms. Not all processes are implemented with MATH
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...?
The relevant one would be "a study".
I don't think that means what you think it means -- it's an artwork aimed at the learner. In music, there are "études" which take the theme of a larger piece as a vehicle for teaching, and students of brush painting often perform a "study" of an established artist's work in which they try to copy it in order to master their brush technique.
The first lens flare meme in filmed entertainment that I recall was in Babylon 5's CGI scenes, and we mocked that even though we loved the show and we weren't film students.
Whether this was intentional or not, lens flare served a rather useful function in early Babylon 5 episodes -- it subtley said "you are not here". Which is fair enough, because you're never going to be floating in space watching shuttles approaching a space station with your naked eye. Early Bablyon 5 was based on the station, and shots outside were establishing shots, or "meanwhile" shots of an incoming spacecraft presaging the latest crisis, or someone leaving, marking resolution. But the viewer, as an observer of the action, was rooted firmly on the space station. In Babylon 5, the action came to you (or at least in the first series or two... the series did lose something as it got older, was it a concidence that it lost momentum when the main characters started flying around in spaceships regularly?
So in a sense, JJ Abrams is being slightly daft and missing the point. By trying to create "immediacy" and "authenticity" by mimicking the look of fly-on-the-wall documentaries, he may in fact be losing it by removing the audience's illusion of being an actual fly on the wall.
The problem isn't people not liking the movie, it is people hating on it, often without even seeing it, because they feel like they SHOULDN'T like it. It is similar to the hipster attitude: Star Trek can't be good because it's popular and popular can't be good. The Onion had a hilariously spot on piece on the first one called "Trekkies Bash New Star Trek Film As 'Fun, Watchable'." There was plenty of that happening. Trekkies hating on it as being "not Star Trek" or getting mad because it was "mainstream" without any real criticism of the movie, just that it wasn't ok to like because of what it was.
I can respect anyone who says "I don't care for this," but doesn't hate on it, they just don't care for it because it doesn't match their taste.
Then let me give you a reasoned argument on behalf of those that just "hate on it": cognitive dissonance. Willful suspension of disbelief is central to all fiction. But contradiction of known "fact" (even fictional fact) breaks your ability to suspend disbelief. I once saw a film where this sicko had been raping children. But he'd already been castrated. Perhaps it is possible to maintain an erection after having your balls chopped off -- this is the sort of detail I would hope the writers would have checked with experts. And yet the truth or otherwise is irrelevant -- I could not immediately reconcile these things, and I was awoken from the illusion, and conscious of watching a film.
I am not a trekkie or a trekker or whatever, but I found it impossible to watch the first film. I could not accept the young Kirk as Kirk (heck, I couldn't accept him as someone who didn't just get expelled from the academy immediately) and assembling all the major characters from the series (including the not-even-in-series-one Chekov) was just far too improbable. For all I know it could have been one of the best written blockbusters of the era, but I would have been unable to see that because I was simply unable to accept the basic premise.
Yes, but this is a reboot of Slashdot. The original Slashdot included many episodes of informed debate focusing on human nature. In the rebooted franchise, there are goodies and baddies, and "-1 troll" means "you're wrong".