Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Moving From Contract Developers To Hiring One In-House?

Soulskill posted about a year ago | from the wipe-his-brain-and-download-stack-overflow-into-it dept.

Bug 524

An anonymous reader writes "I run a small software consulting company who outsources most of its work to contractors. I market myself as being able to handle any technical project, but only really take the fun ones, then shop it around to developers who are interested. I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time. The only 'rule' (if you can call it that) is: I do not pay for bugs. Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs. Then all of a sudden I am asking my contractors to work for 'free' and they can make more money elsewhere. Ugh. Every project ends up being a battle, so, I think the solution is to finally hire someone full-time and pay for everything (bugs or not) and just keep them busy. But how can I make that transition? The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"

cancel ×

524 comments

Sorry! There are no comments related to the filter you selected.

Have u thought about.. (5, Insightful)

woja (633458) | about a year ago | (#43791641)

Hiring contractors you can trust and pay them to fix bugs?

Re:Have u thought about.. (5, Insightful)

Anonymous Coward | about a year ago | (#43791697)

Hiring contractors you can trust and pay them to fix bugs?

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.

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

Half-pint HAL (718102) | about a year ago | (#43791721)

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.

Re: Have u thought about.. (5, Insightful)

e r (2847683) | about a year ago | (#43791769)

You're not a programmer are you? There's no such thing as bug-free code. Just like no writer can proof read his own novel, no programmer can truely find every bug in his own code.

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

Half-pint HAL (718102) | about a year ago | (#43791835)

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.

Re: Have u thought about.. (0)

Anonymous Coward | about a year ago | (#43791855)

Untrue, and this illustrates an unfortunate lack of understanding in computer science. The problem is practicality of practice and economics for nontrivial problems. There are, in fact, hardware and software solutions that are "correct" and without bugs. While this is ideal, a more realistic solution is one in which the outcome is guaranteed not the process.

Re: Have u thought about.. (5, Insightful)

gnasher719 (869701) | about a year ago | (#43791919)

You're not a programmer are you? There's no such thing as bug-free code. Just like no writer can proof read his own novel, no programmer can truely find every bug in his own code.

There is no bug-free anything. Ask someone to put up wallpaper in your living room, and it must be done absolutely perfect. Not one fault. It will take them three times as long. Since you don't pay for that, you will have faults. Ask a gardener to cut back a tree. Bug-free would mean that each single twig is cut to the exact right length. It's not going to happen. Everybody makes mistakes.

As an employed software developer, it's up to my boss to decide where on the time / quality scale he wants me to be (I prefer more time / higher quality myself). Reducing the amount of bugs increases the amount of time. There is an optimum, which also depends on the cost of bugs, but the decision is up to my boss.

The original poster apparently wants the number of bugs down to a level that would make development cost unreasonably costly, while not actually paying for it. My boss also makes an estimate: How expensive to leave the bug unfixed, how expensive to fix the bug? The original poster doesn't seem to want to make that judgement call, because he doesn't want to pay for the cost. On the other hand, his contractors don't want to pay either :-)

Years ago when I worked for a company that contracted out their services, they just sold X hours of development time at Y per hour. At one point I worked as a contractor; I also charged an hourly rate. I did a good job because that's what I do; I pressed more towards quality because higher quality = more hours = more money which I believe benefited the company as well, but there is no way ever I would sign an f***ing contract where someone else can determine how much work I need to do for a fixed amount of money.

Re:Have u thought about.. (1)

chrismcb (983081) | about a year ago | (#43791977)

This man's view of bugs is the right one,

Only if the person he is hiring is PERFECT. I don't know any human being that is perfect.
But as I understand it, he is paying the devs to find their own bugs. But if someone else finds the bug, he won't pay for it.

Re:Have u thought about.. (0)

Anonymous Coward | about a year ago | (#43791985)

I'd like to see a specification that a) defines the program with enough detail that you can actually derive sufficiently specific tests to detect bugs without knowing about the implementation details, and b) is itself free of inconsistencies. In my experience, no such thing exists for any non-trivial program.

Stop being cheap. (0)

Anonymous Coward | about a year ago | (#43791643)

Pay for the bugs. Done.

Stop being cheap. (0, Troll)

Half-pint HAL (718102) | about a year ago | (#43791737)

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.

Pay for the tests (4, Informative)

mangu (126918) | about a year ago | (#43791817)

with the specifications I write there is no excuse for not testing their code.

In every engineering project I've ever worked on, the specifications included acceptance tests. Obviously, his specifications aren't good enough.

He should detail with his customers the functional specifications of the product and generate a set of acceptance tests. The end product of this would be a test procedure, which both the customer and the contractors have previously agreed upon.

There is no excuse for a contractor to blame the programmers who did not conduct testing, if the way the testing should be done has not been previously detailed. The formal test procedure is what separated bugs from features.

Re:Stop being cheap. (1)

Big Hairy Ian (1155547) | about a year ago | (#43791965)

Alternatively can I have double time when the bugs are in the specification or the client moves the goalposts?

Wake up (5, Insightful)

Cenan (1892902) | about a year ago | (#43791645)

Waking up would be a good solution to your problem. You don't pay for bugs? Oh shut the fuck up, if your specs were so masterfully created there would be no bugs. Own up to your part of the miscommunication and deal with it. Put a fault tolerance number into your contracts if your too much of a douche bag to realize that working with humans creates mistakes.

Re:Wake up (3, Insightful)

merovingi (1632365) | about a year ago | (#43791673)

It's good to vent out our frustrations and anger on others especially when they are asking for ideas.

Re:Wake up (1, Interesting)

Anonymous Coward | about a year ago | (#43791719)

Take negativity out, and you pretty much get the answer.
Where people are involved - there will be errors, and in computers they are called bugs.

Also, perhaps hiring someone bright who knows most of languages you need? If you are good with people, which i personally doubt, paying for him to learn one or two languages can also be a solution.(lets say, he has no job to do, he got spare time, make him learn those unusual languages) Don't get me wrong, i am average basement dweller, and i have 0 experience in business, but you needed 3rd party view, I gave my best shot.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791727)

pardon my English. i need to sleep or free coffee, as in one of recent slash dot readings. no free coffee for me :(

Re:Wake up (5, Insightful)

jellomizer (103300) | about a year ago | (#43791819)

Well half of the article is boasting how great he is.
The next part is saying he doesn't trust his work force.
Then he gives a vague business idea without much numbers.
And phrased in in a form of advice.
Sorry, he is only going to get ridiculed for being a pompas ass.

Re:Wake up (5, Insightful)

KraxxxZ01 (2445360) | about a year ago | (#43791679)

Signed. Also "empathy for developers" and " I do not pay for bugs" does not compute.

Re:Wake up (3, Insightful)

Joce640k (829181) | about a year ago | (#43791689)

if your specs were so masterfully created there would be no bugs.

does not compute.

Re:Wake up (1)

hinchles (976598) | about a year ago | (#43791731)

I don't pay for bugs either! My standard contract for contractors is that the project must be completed to specification (I allow for overruns and spec changes etc) but I expect the final product to be defect free at sign off and the contractor to provide bug resolution and support on any code they have produced at no additional cost.

Expecting someone to pay for bugs is like buying a new car with a broken gearbox then having to pay for a new gearbox ontop of the initial purchase.

Re: Wake up (0)

Anonymous Coward | about a year ago | (#43791825)

that is a terrible analogy. cars are not bespoke equipment like software, they are commodity items

Cars dont have bugs WTF ?? (2)

johnjones (14274) | about a year ago | (#43791995)

right and rockets dont blow up because the spec has been followed and tested several times the tolerances tested etc\

never heard of a car being recalled ? - BTW they try not to do this but...

WTF - seriously everyone involved in this thread seems to have very little to say... study some history or repeat yourself...

cheers

John

Re:Wake up (5, Insightful)

BasilBrush (643681) | about a year ago | (#43791869)

Expecting someone to pay for bugs is like buying a new car with a broken gearbox then having to pay for a new gearbox ontop of the initial purchase.

No. A car is a mass produced vehicle. That gives you one standard for what to expect.

Contracting a software project is a one off, bespoke item. Built to your stated requirements (which are unlikely to be perfect in themselves.) It's not rational to have the same expectations as a mass produced item.

A better analogy would be builders building a house based on your drawings. And I hope you ARE a qualified architect.

Now I'm not saying that you wouldn't expect builders to come back and fix flaws. Of course you would. But it wouldn't necessarily come in with the original price. There would be a discussion about who's fault it was that the flaw happened.

But my main point is it's foolish to expect the same flawlessness from a bespoke item built to your specification, and a mass produced item.

Come to that, you could have a car analogy, but it would have to be a custom car, again built to your drawings. And if you expect that not to have flaws...

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791933)

IT is common in construction to not pay for defects and they don't pay for deficiencies in the spec. You must make a working system.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791741)

" I market myself", "empathy for developers." , "I do not pay for bugs" and "Every project ends up being a battle".
This is uncanny! Last time I looked up "asshole incompetent project manager" in OED that is what was written there!

Re:Wake up (1, Offtopic)

Half-pint HAL (718102) | about a year ago | (#43791751)

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.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791757)

I don't agree. In any other line of business, you have warranty repairs. Why shouldn't this apply to software development? If the software isn't according to specs, the customer shouldn't have to pay extra for having the developer fix it. I know this isn't how it's usually done, but there's no reason why it shouldn't.

There will always be disputes regarding what is a bug covered under warranty and what's not, but that would be just as common anywhere else.

Re:Wake up (3, Insightful)

Cenan (1892902) | about a year ago | (#43791879)

Correct. You agree up front what kind of repairs the retailer is responsible for. You don't come running when it turns out that the windmill you thought you ordered turns out to be a batch of tulips. You word the contract appropriately, and you have a process to verify that what has been delivered is the actual wanted product. Saying "I don't pay for bugs" is more telling than anything that this guy has NO process, and no clue.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791759)

This.

Sounds like the project 'manager' needs to be more involved in the project development process if multiple projects are reaching deadlines with unresolvable bugs or specification functionality gaps. Also, depending on where you are in the world, the behaviour of the OP might be considered illegal.

Re:Wake up (4, Insightful)

complete loony (663508) | about a year ago | (#43791763)

If your customers are complaining about bugs, and those conditions are covered by your spec, then you are at fault for not catching it before giving it to the customer. You must verify that the delivered code matches your spec.

Either write automated tests based on your spec yourself, or get a developer to write them and review them yourself. Otherwise you will have to test everything manually, every time they deliver you new code.

But even then, your customer may encounter issues that you didn't test for.

Re:Wake up (3, Informative)

jellomizer (103300) | about a year ago | (#43791789)

Bugs happen even with the best developers.
Not factoring in the cost of fixing bugs into your project is your mistake not theirs.
Often these bugs are not true bugs but misinterpretation of the specs, and needs to be reworked.
Do you rehire good contractors or at least give them as recon adaptions? If so the idea that these contractors will write bugs intentionally just to make money, is rather silly, as they are risking their future jobs.
If you are so masterful yourself and you are also the boss, you should see what the bugs are, and if they make sense, to have happen or if they are just blatantly put in.

Re:Wake up (3, Interesting)

ShakaUVM (157947) | about a year ago | (#43791813)

>Waking up would be a good solution to your problem. You don't pay for bugs? Oh shut the fuck up, if your specs were so masterfully created there would be no bugs.

It's very likely that his developers are, in fact, not perfect, but don't have an incentive to bug fix after they got paid.

Solution: Don't give them the final payment until the customer signs off on it.

Re:Wake up (3, Informative)

Cenan (1892902) | about a year ago | (#43791969)

Yeah, and more importantly he needs to agree with his contractors on what a "deliverable" is, and when one is "done". He might be the victim of poor developers, but since his entire business model is "shopping around" for developers, that's all on him.

Re:Wake up (1)

Anonymous Coward | about a year ago | (#43791831)

This is what is "wrong" with IT in general.

In what other industry in the world would it be acceptable that a consumer of services be expected to pay to put right defects and problems with a supplied product? If I go into a shop or store and buy an item such as a pair of trousers which doesn't have pockets and I'd asked for a pair of trousers with pockets then I wouldn't expect to pay for pockets to be sewn in.

It is absolutely true there is a difference between a bug and a feature or capability that was never requested but your attitude fosters sloppy coding, poor practice and displays a complete and utter contempt for the person who is PAYING YOU.

Seriously, if I've asked you to code a widget that does xyz and y doesn't work I'd damn well be expecting you to fix it at YOUR expense, not mine. It requires an excellently well written and clear brief, clearly defined specs and all those good things of course but end of the day if I've asked you to code x, you quoted me a price to code x that I've agreed to then when you finish x I damn well expect x to do everything I've asked for without defects or bugs. To come and state the individual has "misconceptions" because he expects something he has paid for to, well you know, work is just as bad and perpetuates the disgraceful state of affairs (or great PR job depending on your view) the software industry has managed to convince the law makers to adopt.

G

Re:Wake up (4, Insightful)

CptNerd (455084) | about a year ago | (#43791887)

Most of the time the customer asks for xyz and doesn't tell the developer about w, and complains that it's not there. Or the customer forgets to tell the developer that their data integrity isn't checked, and that data outside the spec sometimes slips in. Sometimes the customer forgets to mention that other systems are used with the data and will sometimes make changes to the data that weren't documented in the spec. Putting all the blame on the developer is nice from a pure management perspective, but it breaks too often in the real world.

Re:Wake up (4, Insightful)

Cenan (1892902) | about a year ago | (#43791917)

Of course you fix your bugs - this guy however signs off on code and then expects to be able to un-sign off on it at a later date. That is not how sane software development works. You boil down tests in every phase to a yes/no response, and that is your basis of signing off. If he signed off on shit, then it later proves to be shit, then that is all on him for not doing proper unit/integration/acceptance/whatever testing. So yeah, again, fuck him - his type is what is wrong with software development - he acts the middleman and peddles absolute shit to paying customers and expects to pass the turd on to someone else.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791851)

If you think I would give you any work based on your post above, you're mistaken.

No one is saying humans don't make mistakes, but if I'm paying for a job they better be minimized and that sounds like what this guy is dealing with. He's dealing with trying to be very fair with his guys, and they are pushing back at the point where they have him over a barrel.

Re:Wake up (1)

Cenan (1892902) | about a year ago | (#43791929)

No - he is dealing with his own lack of a process model. I wouldn't take work from him or you either, what I would do is go straight to your customer and offer a better product at a cheaper price, because I know process models and I just cut out the greedy middleman.

Re:Wake up (0)

Anonymous Coward | about a year ago | (#43791857)

Having been a dev and test lead for many years this smacks of the 'I only write stuff' attitude I encountered in what I termed 'coders' not 'software engineers'. Software engineers, in my book were the folk who understood the job is not done until it meets the need (not necessarily the spec) and is to the correct quality.
If you don't care about the quality of your output I struggle to see how the industry will progress?

Re:Wake up (2)

Cenan (1892902) | about a year ago | (#43791947)

I certainly care about the product I deliver. I don't care much for middlemen though, and I certainly don't care for middlemen who thinks their job is done when they deliver the specification. Where was the acceptance testing? Why was this code signed off on? Why does he even have this problem to begin with? He sets himself up to sound like a fucking legend, yet it smells to high heaven of greed and incompetence.

Re:Wake up (5, Interesting)

Bearhouse (1034238) | about a year ago | (#43791897)

Well, a little rude, but not totally wrong.

1. I've been told I write "excellent" specs before; notably on one project where the devs then went 3x over budget, (estimated AFTER they had read the specs). Even before this experience, I never believed such a thing as an "excellent" spec existed. A little humility, guy...I'm sure you're good, but is everything you do "excellent", everywhere and every day? Anyway, spec has very little to do with the ability of the team to translate into code. I've known plenty of people capable of turning a bad spec into good product, and vice versa.

2. As the OP said, add a realistic budget into your contracts for testing & bug-fixes. That will help you build loyalty into your core team of contract devs. You're better off sticking with a regular team who you can trust, especially as you're asking for a very wide competency base.

3. Don't hire fixed costs; they'll kill you, and it sounds like your hiring criteria are totally unrealistic anyway. Also, your logic is flawed; why would you be prepared to pay a salaried employee to fix (his/her) bugs, but not a contractor?

Re:Wake up (1)

terminal.dk (102718) | about a year ago | (#43791971)

Not only that, if he is such a master as he claim to be, he would detect the bugs when things moves along, and there would not be the pile in the end.
IMHO most of the "bugs" are not really bugs, but changes. Customer don't like that button etc. Most often when the product does exactly what is specified, the customer is unhappy. That is what comes from pre-project specifications. Expect 50-100% extra time making things like the customer wants it, rather than what he told you he wanted.

Or change development method. Pragmatic programming / LEAN etc. Have the customer (or yourself if you think you can read the custumers mind) see the intermediate results / the developing prototype, and they can change things as they go along. Total price will probably be cheaper.

Fall back asleep. (1)

neoshroom (324937) | about a year ago | (#43791991)

I am a contract software developer and have this exact same same policy myself. That is, when I get a client I ask for detailed specifications and we put them on paper. Then I go to work on the project. If when done they want a feature that isn't in the spec, we create a new milestone and they pay for it. If they find a bug and want it fixed, I fix it for free. It's just another way of saying "I guarantee my work."

There is no possible way that masterful specs can eliminate all bugs. In fact, I'm guessing you don't quite understand what he is referring to by "specs." Typically, specs from non-developers are a list of features they want, things they want the program to do, what they want the workflow to be and possibly how they want the program to look or wireframes. This isn't things at the level anywhere near code or pseudo-code and so it isn't really possible to eliminate bugs at this level. Putting a fault tolerance number wouldn't even help because whether something is one bug or two bugs is often somewhat arbitrary and some mythical evil programmer could easily put intentional bugs in the program to run through this artificial limit (which is why I'm pretty sure Microsoft uses the system you described...;) ).

I've been using basically the same policy he describes for years without issue. So, my advice to you is chill out and my advice to the poster is I'm sure there are other developers like me out there who you could use for contract freelancing. I mean, you wouldn't hire an architect who would built you a house but if there are structural problems post-construction would refuse to repair them at no cost (or would only repair three and after that you have to pay him extra). It's a pretty reasonable policy.

Sounds like a partnership (2, Interesting)

Anonymous Coward | about a year ago | (#43791651)

You can always offer stock options, a share of the company/profit etc. If you're as good a manager as you say, getting someone on board shouldn't be that difficult.

Hiring? (2, Insightful)

Anonymous Coward | about a year ago | (#43791653)

How about hiring a decent tester and catching the "bug" a lot earlier?

Outsource to cheaper place. (1)

kampangptlk (1252914) | about a year ago | (#43791655)

Outsource to someone who can understand English, has good reputation, from countries with smaller pay / hour.

Why don't you pay them like everybody else? (0)

Anonymous Coward | about a year ago | (#43791657)

....payment by results, where results involve sign-off for the code after it has passed through the customer's independent test and acceptance process?

Are you actually saying that you do not have such a process, and that people get paid once they have delivered code which they claim meets your specs? If so, that's where the problem lies...

Re:Why don't you pay them like everybody else? (1)

Ice Tiger (10883) | about a year ago | (#43791745)

Agree, you need to have some acceptance criteria and process where you pay for functionality that you have deemed acceptable. The product specs and so one would form part of that criteria along with any testing cases to support it.

Once past that stage any further bugs that come to light after acceptance is a paid for change request as you've accepted the unit of work and have to have taken responsibility for it being deemed correct.

Software development is like creating a prototype for something new every time, if it wasn't you'd just buy or subscribe to an existing service. It's the nature of the beast that bugs will crop up that might not even be captured until hit by an edge case that the user creates no matter what spec etc have been written.

Finally you saw what happened at Jurassic Park when the 'I won't pay for bugs no matter what' line is taken :)

Don't do business in California. (1)

Narcocide (102829) | about a year ago | (#43791665)

You will get sued for that crap here.

Try a different approach (0)

Anonymous Coward | about a year ago | (#43791667)

Well, you should be paying them to fix bugs really... it's analogous to not paying a sports team if they lose. I'd be surprised that you'd get developers of any real quality with that approach, especially if you're mentioning it up front. Despite best intentions and well authored specs even the best developers are going to miss some things. Maybe some Utopian world exists somewhere where bugs don't exist, but it ain't this one. A better approach might be contracting a decent tester to work with your developers?

Re:Try a different approach (1)

Half-pint HAL (718102) | about a year ago | (#43791767)

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

Re:Try a different approach (0)

Anonymous Coward | about a year ago | (#43791889)

A bug in a computer program is not like getting sent the wrong book, it's like an error in a book. Try to return a text book because the proof of theorem 20 is erroneous. Good luck.

Re:Try a different approach (0)

Anonymous Coward | about a year ago | (#43791893)

It would be analogous if you had a separate team of coders working against you, like it happens in (most) team sports. If anything, I'd say software development is more like golf, where the final result depends solely on your own skill (for the most part) even if, at the end of the competition you get ranked against others. And, still, when comparing to any kind of sport we're leaving out the element of chance or luck.

Completion Bonus (5, Interesting)

CaptQuark (2706165) | about a year ago | (#43791675)

Hold back 10-15% of the total cost as a completion bonus. Pay the completion bonus when the project reaches a completion milestone of no critical bug reports for three weeks or version 1.1 coding begins.

This gives the programmers an incentive to finish the bug testing and getting to a stable release status so they receive their bonus.

Many contractors have a bonus waiting at the end of a project and know that any mistakes will come out of that bonus. If a new contractor is needed to fix something the original contractor is unwilling to do, then the bonus should be just large enough to pay for the new contractors work.

Re:Completion Bonus (1)

Anonymous Coward | about a year ago | (#43791733)

Hold back 10-15% of the total cost as a completion bonus. Pay the completion bonus when the project reaches a completion milestone of no critical bug reports for three weeks or version 1.1 coding begins.

This gives the programmers an incentive to finish the bug testing and getting to a stable release status so they receive their bonus.

Many contractors have a bonus waiting at the end of a project and know that any mistakes will come out of that bonus. If a new contractor is needed to fix something the original contractor is unwilling to do, then the bonus should be just large enough to pay for the new contractors work.

I wish to mod this up.

Good luck with that! (5, Insightful)

Kwyj1b0 (2757125) | about a year ago | (#43791681)

But how can I make that transition? The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"

So let's see: you want (a) A person who knows a lot of languages, (b) Proficient in all of them - i.e. many years of experience, hopefully very skilled (i.e. not resume padding), and (c) Relatively inexpensive.

Good luck with that. You can't have all three. Hell, getting one really good developer who is inexpensive is hard. Fresh out of college, sure. Someone who has a lot of real world experience in a lot of languages? Nope.

Also, since you are talking about difficulties with transition, you want your outside developers to either do a knowledge transfer, or the new guy to spend time reading the old stuff independently - i.e. it will take him/her weeks (if not months) while learning, making it a loss of money early on. If you want to make a clean break (and not support your old work), then you can skip this step (assuming you found someone).

And finally, you do NOT pay for bugs? Then recover your costs (SLAs) or do your testing and refuse to pay till the code is clean. Saying developers are fine with it till bugs are brought to light means that the developers are not fine with it! And assuming your specifications are great ("there is no excuse for not testing their code") then either the devs are keeping testing to the end, or the timeline is too stringent, not giving enough time for testing. So your project management skills aren't great (you are being optimistic in what you tell your clients as a schedule), or you are picking lazy developers.

Ever project ends up being a battle...

So you don't learn from your mistakes either? Why do assume moving things in house will solve all your problems? The common factor for a lot of your projects seems to be you...

100k/year sounds low. (0)

Anonymous Coward | about a year ago | (#43791683)

That said, you could offer principle in your business in addition to direct compensation. Someone disciplined and good probably expects more than 100k/year.

And now for a derail: There are always bugs, and for a reasonably complex project they're probably most of the actual development time (testing or not). I'm surprised anyone agrees to your terms.

Re:100k/year sounds low. (1)

jellomizer (103300) | about a year ago | (#43791837)

Depend on location.
In Boston or NYC, that pay is low. In Albany that is a really good salary for skilled workers.

Every project ends up being a battle? (0)

Anonymous Coward | about a year ago | (#43791687)

Every project ends up being a battle because they aren't writing 100% bug free code first time (for anything moderately complicated no one can) and you refuse to pay them to fix bugs?

Am I missing the point or is this entirely a problem of your own creation?

Re:Every project ends up being a battle? (0)

Anonymous Coward | about a year ago | (#43791715)

>for anything moderately complicated no one can

utter twaddle. go look up test driven development.

Re:Every project ends up being a battle? (0)

Anonymous Coward | about a year ago | (#43791735)

Oh great - 100% perfect tests that cover every possible eventuality. No mistakes ever!

It must be great living in 'no fucking clue' land!

Re:Every project ends up being a battle? (0)

Anonymous Coward | about a year ago | (#43791815)

Well, you could write extremely simple software (like a NAND gate)... but you would have to do it with relays since no CPU/chipset is bug free (or OS). But I guess that would not work either since relays might develop whiskers and you would have bugs again... I would suggest a mechanical hand driven device that is made out of brass and is services before every execution... but what about the human factor. WAIT! I got it; you could make a mechanical NOP that would be 100% bug free! (depending on the input, if it has electrical input and the input is too high it might bur it out and you would not have a NOP but a HALT). Damn! Its hard to make a 100% bug free system!

Re:Every project ends up being a battle? (1)

scsirob (246572) | about a year ago | (#43791883)

If your tests find zero errors then the bugs are in your test procedures as well.

best practice employment practices (1)

gbjbaanb (229885) | about a year ago | (#43791691)

in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time

hardly true. If you want 100% bug free code then expect the devs to take twice as long to provide the solution (and that's being optimistic). If you don't want the tested-to-death solution, and want to take a pragmatic approach where you assume some bugs will fall through the dev process, then you'll get the solution quicker overall. (obviously there are some devs to whom a bug is a way of life, I assume you will not hire them again)

BTW good for you, not wanting devs to work weekends. Do they get national holidays off too? You are just the kind of empathic boss Dilbert would die for.

scrum (0)

Anonymous Coward | about a year ago | (#43791699)

specs? are people stilll writing specs? how wonderfully waterfall of you.

use agile techniques.

for example...

2 week sprints. you are the product owner. split your "spec" into stories (thin vertical slices of the system). you and the contractor negotiate how many can be done in a sprint. at the end of each sprint he delivers you *working software*, you (or the real customer) test it and pay for the two weeks. if its buggy you dont pay. if all was well you pick the stories for the next sprint.

repeat.

if you've never come across scrum or xp before you have some reading to do.

Re:scrum (1)

prionic6 (858109) | about a year ago | (#43791799)

Great, if the customer is prepared to pay for n sprints, without knowing n before the end of the project.

Re:scrum (0)

Anonymous Coward | about a year ago | (#43791829)

Even agile developers write specs. It's just that those specs are automatically testable, and thus go under the name "test case".

Re:scrum (1)

crutchy (1949900) | about a year ago | (#43791963)

Even agile developers write specs

program spec;

uses
    dialogs;

begin
    dialogs.showmessage("hello spec");
end.

Dear Slashdot, (0)

Anonymous Coward | about a year ago | (#43791701)

I need a full time bug fixer but I'm too cheap to pay one.

Please help me.

Uh ... yeah -- (0)

Anonymous Coward | about a year ago | (#43791703)

The guy I'd need to hire would have to know a lot of languages and be proficient in all of them. Plus, I can't afford to pay someone $100k/year right now. Ideas?"

Yup: Get a new business plan where you can afford to pay for that which you wish to purchase. You know - services in, money out. It's like yin/yang - a balance.

Every project ends up being a battle [...]

Dare I suggest that it just might be possible that you are not the genius project manager that you think you are?

Why is this on /.? (0)

Anonymous Coward | about a year ago | (#43791707)

This must be the dumbest thing I have ever read here. That OP is a total idiot is one thing but why is Soulskill not doing his job as a shit filter? This should have been sent to write only storage as soon as it got here.

Re:Why is this on /.? (1)

crutchy (1949900) | about a year ago | (#43791945)

you just can't help being a douche bag can you... go lick a window you drooling brain dead vacuum cleaner fucker

In denial much? (2)

dsmithhfx (1772254) | about a year ago | (#43791709)

"I do not pay for bugs" Actually you do, but you clearly don't like it.

If you are going to wishing for things (1)

OzPeter (195038) | about a year ago | (#43791713)

If you are going to be wishing for things like the perfect employee (knows lots of languages, is proficient in all of them, is cheap) then you might as well just wish for peace on earth, good will to mankind .. and a pony.

And while you are doing that, take a look a what people with experience in only a few areas are being paid, and then factor in some overheads. Or in other words, is that $100k as salary to them and you will have a bunch of overheads to carry, or is the $100k including overheads? Because if it is the latter then you are going to realistically be offering well less than $100k salary.

You get what you pay for, and if you cheap out on a salary you are not going to get people anywhere near as good as you think you need which has the potential to damage you business.

Find a way to catch bugs earlier? (0)

Anonymous Coward | about a year ago | (#43791773)

Sounds like a nice setup you have there, but seems odd that either you or the contractors are surprised that there are bugs come the end of the project. Also sounds like the contractors are might be in the easier position at that point because they can just walk away.

Is there any way that you could alter your project plans to catch bugs before the end of the project? Smaller deliverable within larger projects?

Or employ someone at a more junior level (easier to teach and mentor?) and use them to look for issues as code is created by your contractors?

Re:Find a way to catch bugs earlier? (1)

crutchy (1949900) | about a year ago | (#43791921)

Is there any way that you could alter your project plans to catch bugs

use heavier paper to print them on... when you go waving it at the bugs they won't have a chance

You do not pay for bugs? (0)

Anonymous Coward | about a year ago | (#43791779)

So, do I understand you correctly, if the code you get has bugs, you don't pay the developer for it? Well, hopefully you then at least consider the code copyright still belonging to the developer. Because otherwise, it sounds like a scam to get code for free (because face it, every non-trivial code will have bugs). I can understand that the developers would not be happy with that.

No such thing stable software. (0)

Anonymous Coward | about a year ago | (#43791781)

I think you just a marketer. get 40% down payment. push to developer to build. then paid the developer 10% value. if bug you chase developer. lol..

Software *is* bugs (0)

Anonymous Coward | about a year ago | (#43791793)

If I'm reading this correctly, all your issues come from one assumption: you are assuming that "the right spec should produce no bugs". I'm afraid that's impossible. Bugs don't occur because incomplete or missing specs, at least not only. At the end, they occur because probrams are written by humans. And humans make mistakes. A spec, no matter how well written, can't "fix" that.

You are not structuring your incentives to match your needs (or your clients') on that false premise. Once you have payed them, the devs will (naturally) not have any incentive to fix any bugs for free.

Most projects actually accept that bugs are inevitable, and set aside an amount for fixing them. It is usually called "maintenance". I encourage you to try that. Your developers won't work for free, and everyone will have the right expectations.

Also, notice that this doesn't mean you will pay more; you could try lowering your rates per hour a bit, so that the project costs you more or less the same (less $$ per hour, but more hours). Etc.

As in any other business, the trick is knowing what everyone wants, and finding the right compromise.

Re:Software *is* bugs (2)

CptNerd (455084) | about a year ago | (#43791865)

Not to mention that for any project maintenance is the largest percentage of the project's lifetime. It kind of sounds like this guy doesn't really understand what constitutes a "bug," at least doesn't understand that not all bugs are caused by developers making mistakes. There are bugs caused by invalid data entering the system by user error, or by parts of the system outside the control of the developers, or by bugs in the compiler or libraries used in the system that only show up during run-time, or by changes in the business rules after development starts, and many many other causes. To hold the developers responsible for finding these beforehand, and refusing to pay for any work needed to come up with fixes or work-arounds, sounds like he's not really interested in maintaining the systems he builds.

He also sounds like a real peach of a guy to work for in other respects, as well. I wish him good luck in finding his cheap experienced expert developer.

Respectfully (0)

Anonymous Coward | about a year ago | (#43791803)

Go fuck yourself!

There's no such thing as non trivia bug free code (2)

HungryHobo (1314109) | about a year ago | (#43791809)

There's no such thing as non trivial bug free code. only code which has not been tested in enough circumstances.

No. really. Even limiting it to just security related bugs with an author who put an insane amount of work into making it bug free who knew exactly what he wanted with no communication with a client bugs still turn up when code is exposed to the real world.

http://en.wikipedia.org/wiki/Qmail [wikipedia.org]

Totally bug free code is insanely expensive to write in even small amounts so you're basically having the developers spin the wheel, if your clients do massive amounts of testing they end up working for months unpaid. if they do little testing and can live with lots of little bugs then the Dev gets a good deal.

Here's a sane solution to your problem: pay for bug fixing.

Re:There's no such thing as non trivia bug free co (1)

Daniel Oom (2826737) | about a year ago | (#43791993)

It may be expensive to write bug-free code, but it is always better than having software with bugs in it (which you then have to test and fix).

Change your payment terms (1)

Anonymous Coward | about a year ago | (#43791833)

Wow, lots of vitriol in this thread. I think you pissed off some developers >: ).

Based on what you've said, and the sounds of having done multiple projects, you should just switch your tactic but still using contractors. Personally, using contractors can be cost effective, but managing them is the difficult part. It sounds like with the exception of bugs, you're managing them well enough.

The best approach is to negotiate milestones and have your contractors sign off on it at the beginning of the job. The most important milestone being acceptance of completed project by customer. This is standard practice, I agree you shouldn't be paying for bugs. If your spec is detailed enough, you shouldn't be paying by the hour but I understand some guys do to keep contractor costs under control.

Empathy is a good skill to have, but remember this is business on all sides. Contractors get the benefit of charging more than full-time employees, but you have advantages as well when you hold the purse strings.

Project management includes handling QA. (2)

joe user jr (230757) | about a year ago | (#43791849)

"with the specifications I write there is no excuse for not testing their code" - so why don't you test their code, then? (If you can't do this yourself, hire QA.) Regard the contract as complete when all your tests pass (note: *your* tests!).

If bugs are found after the project is complete, it is because the test coverage was incomplete, or QA failed, and you should be happy to take responsibility for having them resolved (including payment if necessary.)

Learn how to code (1)

scsirob (246572) | about a year ago | (#43791853)

Writing very good specs means having a good understanding of the business needs for that project.
Both getting to understand the needs and writing great specs take a lot of your time and effort.

So perhaps you should learn how to code yourself. Spend just as much time understanding the business problem, then write the specs in a brief way (you obviously know what you need to do anyway), then code it yourself. No miscommunication possible. Any bugs are yours and yours alone.

I'm pretty sure you will gain a lot of respect for those who do coding as a living..

Sounds reasonable to me (2)

GeoSanDiego (703197) | about a year ago | (#43791863)

I am a developer who also has some experience paying other developers for a project. I do not agree with some of the criticism you are getting. If you say up front you won't pay for bugs then the developer should not accept the work if they don't want to work under those conditions. It is easy to say "all code has bugs" but it is also true that cleaner and well thought out code will have less bugs and the more unit testing that is done on code the less bugs it will have. Why reward sloppy behavior? Nothing wrong with getting developers to own it. The project I subbed out was a fixed priced project. Bugs and omissions were plentiful, and although I wish the developers were more careful, at the end of the day it was their own time that they were expending on fixes.

Re:Sounds reasonable to me (0)

Anonymous Coward | about a year ago | (#43791989)

If he wants to sub out a fixed priced project he should just say that. Saying you're not paying for bugs is foolish because there's no way you're not paying for every piece of code in one way or another. You're not paying for the hours it takes for the developers to go back and fix bugs? You might not be out of pocket extra money, but you'll never get those hours you didn't have "what you paid for" back. All code probably has some bugs because as everyone has pointed out, it's impossible, yes, provably not possible, to test the entire operation of any amount of non-trivial code in a reasonable amount of time. This is a known thing in computer science. I think I learned it in the first CS class I ever took. How any developer can pretend like it's only due to incompetence or not enough rigor is beyond me and luckily most of the posters agree.

Acceptance tests for the contractor (1)

rvw (755107) | about a year ago | (#43791873)

In your contract, you should have acceptance tests specified. The contractor that hires you should test and approve the product. If it's not what they want, contains bugs, or is not as specified by them, they should not accept. When they have accepted the product, they should pay for bugs. You should agree about this before starting.

For now, fix those bugs, and think of it as a good and valuable lesson.

Not in touch with reality (4, Insightful)

eennaarbrak (1089393) | about a year ago | (#43791877)

Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code.

This hugely contradicts my experience. Although it may be possible to write specs that are so good, so coherent and incorporate so many edge case that any code realizing it *must* be bug-free, I have never seen it happen for any modestly complicated software project.

Software development is a continuous process (like gardening). If you are worried about bugs, then you must be pro-active about it. Tools like Sonar can give you valuable information about which parts of the code base are under-tested, overly complicated and require careful attention. Also, testing is a multi-level discipline - you can't get away with *only* unit testing, or *only* integration testing. If you want your code to be bug free, you need to invest a lot of time and effort in automating your different test strategies.

There is no guaranteed, affordable process for having bug-free code. You *will* end up with bugs, without requiring this to be attributable to someone's incompetence. You need to actively manage this.

Re:Not in touch with reality (1)

CptNerd (455084) | about a year ago | (#43791913)

No matter how thoroughly tested software is, there will be places where it breaks in production, through no fault of the developers and testers. If you don't believe this, you haven't worked on enough systems, or they haven't been complicated enough.

Start by being honest with yourself (1)

Anonymous Coward | about a year ago | (#43791905)

Quote:
"I market myself as being able to handle any technical project, but only really take the fun ones..."
"I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers."
"I do not pay for bugs."
"...with the specifications I write there is no excuse for not testing their code."
"Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs."
"Every project ends up being a battle."
"The guy I'd need to hire would have to know a lot of languages and be proficient in all of them."

So you're a great salesman with a perfect pitch, until it's time to deliver the final product and the whole project unravels as a sordid mess. Of course, "bugs" are the developers fault, and as long as "they are fine with it", everything looks great! Until the customer sees the final result of course, and starts demanding getting value for money..

The best advice I can give is: Be completely honest with yourself! Question everything!

You're a great PM? Says WHO? I'm sure you have a great personality and are a good marketing / salesman guy, which is a good start to start your own business. However, if you're going to stay in your current role without burning out, you and "your" developers, you need to completely rethink your attitudes towards project management.

To start:
What are the critical success factors, the most crucial outcomes, for the customer?
Did you spend 50% of the time on gathering and refining requirements from the CUSTOMER? Are you completely sure your customer knows what he wants, and that you FULLY understand the scope of EACH and EVERY requirement? How many iterations did you walk through the specs with your client and developer?
Did the customer sign off the specs, SLA and test cases (what is the acceptable level of quality?), and you are fully confident the customer knows what he's getting and what he's not getting? Are you fully confident all the developers and customer is on the same page?

If you truly want to improve the process instead of blaming your developers and neglecting your customers for lengths of time, I suggest you learn "Lean IT", and apply what you can to yourself and the processes you can affect positively. Sadly, you can't really change all customers / clients, so a PM should expect some fires in their projects. However, with the right focus on quality and drive to get ROI, you should be seeing improvements quite soon if you're truly any good (DO expect to work weekends in the beginning). To succeed, you NEED to be hungry for it, and stop patting yourself on the back!

To be blunt: Going the other way, from lean to a "thicker" model, where you're expected to provide to the livelihood of someone else, I suspect these same problems will pop up, but then you're stuck with what you have so it's either do or die. I suspect you stay afloat now by running away from your problems, which is not going to work when actually hiring someone for good.

I like the fact that you take on the fun projects! When you truly follow the heart, you will find ways to make it work and things will go more smoothly. Just make sure it's not just fun for you, but also for the customer and developers. I sense you have a happy spirit behind this all, and that is a great start. So what can be done as early in the process as possible, to keep the happy spirit throughout the entire project? True happiness is the only true measure of success, and also, with happiness and good spirits, success will tend to chase you, and not the other way around.

One language to rule them all (1)

Ruliz Galaxor (568498) | about a year ago | (#43791909)

The guy I'd need to hire would have to know a lot of languages

There's your problem right there. If you are doing in-house development, you should stick to one language. Especially if you have a small company, but it kind of holds up for larger companies as well.

e.g. if you have four programmers, two proficient in C, two in Java and a Java programmer quits, then suddenly your single Java programmer needs to do all the Java work. If you have 4 programmers proficient in Java, then if one quits, you still have 3 Java programmers left.
In the end multiple languages just means less flexibility in capacity.

automate as much as possible (1)

crutchy (1949900) | about a year ago | (#43791911)

if your problems are bug related, maybe focus your contracting efforts on testing, validation and verification because that's the stuff that you shouldn't rely on yourself to do, and you shouldn't rely on your contractors to test their own code either.

you then need to write your code to take most advantage of the testing. don't just test once. test, record the test, and use the recorded test in automated regression testing so that the test can be repeated for every build (without having to pay for a tester to repeat the same test manually).

also, everyone knows how important it is but few do it... unit testing... code the test before you code the function to be tested, and don't skimp on unit testing. some think you must unit test absolutely everything, but they are fruitcakes. test what you must, but test those things properly. a poorly designed test isn't much better than no test at all.

Remote "in-house"? (0)

Anonymous Coward | about a year ago | (#43791925)

I'm not sure what the outrage is about - not paying for bugs is a reasonable policy to strive for. But you DO have to pay for testing and bug fixing as they are important pieces of the software production cycle.
In my experience for general-purpose development you need a project manager, developer, tester and designer. Those don't really need to be four different people, but it's also unreasonable to expect one guy to do three or four of those jobs while being proficient in all languages and technologies required for your various projects. It's also generally more expensive to have your developer twiddle with UI or do his own testing.
Anyhow, I think you can still pull it off given a certain definition of in-house. Example: I'm from Eastern Europe and I've worked full time for US-based clients (with contracts and everything). $50k is quite enough to get a top-notch developer here. Personally I've done projects for iOS, Android, Windows mobile (complete with reading credit card data and payments over 3G), both front-end and back-end development for web sites, C++/Python search engine, plugins for Photoshop, small Java desktop apps and even software for car clusters (FYI that's what they call the dashboard electronics) in C. While it's not exactly easy to find good experienced developers here (or anywhere else) it's definitely possible.
In short there are quite a few places in the world where $100k per year gets you a small office and a competent development team that will work for you full-time.

no fit all response (0)

Anonymous Coward | about a year ago | (#43791941)

if you're the boss then
    hire one in house
if you're the contractor
    don't accept in house job

you seem to be the boss. Want to hire a real good one?
aim for 25-30 years old with not so much professional experience BUT a huge amount of collaboration on open source projects that can show off his own projects via github or else.
Put priority on the young geek with a decent ego that has 10 years+ of linux background as a hobby.
It's hard to find but not impossible. You'll get more for your money than say a 30ish contractor like me who will charge 5KE net/month.

It can be the other way around depending on the length of your projects (6 months ? then go for a contractor, more than a year? go for inhouse)

you have to balance the length of the projects where your geek will be active, the knowledge required for the project and how much who want to put in his salary.

there is no fitting response to this question, it's a balance between your requirements (type of project, length, money to invest etc...)

Pay to Test or Pay to Fix (1)

fishous.com (1057048) | about a year ago | (#43791955)

I had a problem when contracting that the client didn't want to pay me to fix bugs. I told him he could either pay me to test it for 8 hrs, or he could pay me for 15 minutes here and there to fix tiny bugs.

mokd down (-1)

Anonymous Coward | about a year ago | (#43791975)

the pmroject to [goat.cx]

If every job is a battle (0)

Anonymous Coward | about a year ago | (#43791983)

Then you're doing it wrong. Let me try and explain with your points:
I run a small software consulting company who outsources most of its work to contractors. I market myself as being able to handle any technical project, but only really take the fun ones
Fun for who exactly. You should be taking work based on your known good contractors, their availability and the cost of the project. Fun is a meaningless adjective you've added to make yourself seem like a nice guy. This is a lie any programmer will see through.

I write excellent product specs, provide bug tracking & source control and in general am a programming project manager with empathy for developers. I don't ask them to work weekends and I provide detailed, reproducible bug reports and I pay on time.
Paying on time is the only thing of worth here. It's not hard or expensive to set up bug tracking or version control. If they're contractors they work their own hours, so your weekend point is totally redundant.

The only 'rule' (if you can call it that) is: I do not pay for bugs. Developers can make more work for themselves by causing bugs, and with the specifications I write there is no excuse for not testing their code. Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs. Then all of a sudden I am asking my contractors to work for 'free' and they can make more money elsewhere. Ugh. Every project ends up being a battle
Oh boy, Mr Empathy has turned into Mr Hollow in one sentence.
I'm guessing you're the type of employer that doesn't pay people when they get sick? After all they could have taken more precautions, right?
Contractors should be measured by cost vs average, quality vs average, ease of working with vs average, time to deliver vs average. You're so far off the ball here it's not even a joke.

If you're wondering why each contract is a fail (in your words) this is why.

Solutions:
Pay for all the work, bugs, feature changes, everything that person does.
Pay on time.
Listen to your contractors and make sure they listen to you.
Choose contractors that don't make thousands of bugs to pad their payslip, make working relationships with good contractors, make sure they're available for the jobs.
Question their bugs if you think something is fishy. Get advice from a contractor you trust.

If you've burned all your bridges by burning all the good contractors then honestly you're stuffed. Stop exploiting people so you can make a living.

If you want some-one cheap, then get someone who you can train. Can't train them because you don't have the knowledge? A bit of a pickle really.

Bottom line is, treat your staff and contractors as human beings and maybe you'll reap the reward. Treat them like thieving sub humans and enjoy a stressful and unhappy life.
 

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>