Forgot your password?

typodupeerror

Comment: Re: Have u thought about.. (Score 1) 460

"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.

Comment: Re:Have u thought about.. (Score 2) 460

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.

Comment: Re:Have u thought about.. (Score 1) 460

"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.

Comment: Re: Have u thought about.. (Score 4, Insightful) 460

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.

Comment: Re:Try a different approach (Score 1) 460

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..."

Comment: Stop being cheap. (Score 0, Troll) 460

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.

Comment: Re:Have u thought about.. (Score 5, Interesting) 460

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.

Comment: Re:my two cents (Score 1) 141

by Half-pint HAL (#43780581) Attached to: What Professors Can Learn From "Hard Core" MOOC Students

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....

Comment: Re:Little to Learn About Mass Education from Outli (Score 1) 141

by Half-pint HAL (#43780375) Attached to: What Professors Can Learn From "Hard Core" MOOC Students

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....

Comment: Re:What is it I am supposed to learn? (Score 1) 141

by Half-pint HAL (#43780319) Attached to: What Professors Can Learn From "Hard Core" MOOC Students

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.

Comment: Re:Wide access, high standards and high completion (Score 1) 141

by Half-pint HAL (#43780259) Attached to: What Professors Can Learn From "Hard Core" MOOC Students

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"....

Comment: Re:How much do I learn? (Score 1) 141

by Half-pint HAL (#43780199) Attached to: What Professors Can Learn From "Hard Core" MOOC Students

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.

Comment: Re:Does that mean? (Score 1) 116

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...?

Quark! Quark! Beware the quantum duck!

Working...