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

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

Comments

Have u thought about..

[woja]

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

Re:Have u thought about..

[Anonymous Coward]

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

[Half-pint HAL]

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

[erapert]

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

[Half-pint HAL]

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

[gnasher719]

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

[XopherMV]

As a contractor when I submit code, I leave a certain amount of time for the customer to test that code and supply me a list of bugs. I fix that list. Once my contract time elapses, I expect sign-off and payment. I've fulfilled my end of the contract. I expect my customer to fulfill his end. If he doesn't pay, then I'll send my bill to a collection agency.

My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.

Re: Have u thought about..

[Xest]

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

If you feel the contractor's work wasn't of sufficient quality then either withhold payment and dispute it legally with them or just don't ever hire them again.

The whole point in using contractors is that you can get rid of them in an instant with no questions asked, no redundancy payment, no justification required. Maybe this is in part a cultural difference because I understand some US states even allow the firing of permanent employees at will, but certainly here in the UK the benefit of contractors is the flexibility they allow you in staffing up or down as required above all else - if you don't like the work they're doing then kick them out the door immediately.

Re: Have u thought about..

[Registered Coward v2]

As a contractor when I submit code, I leave a certain amount of time for the customer to test that code and supply me a list of bugs. I fix that list. Once my contract time elapses, I expect sign-off and payment. I've fulfilled my end of the contract. I expect my customer to fulfill his end. If he doesn't pay, then I'll send my bill to a collection agency. My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.

Excellant points. Good program management requires testing as you go to eliminate bugs; especially since bugs can result in later programming decisions to develop work arounds, which, then bug is fixed, now become problems themselves. If the If the specs are as good as he claims, testing should be straightforward and either the code meets the specs or it doesn't.

In addition, what is a bug? I've seen situations where code A meets its spec but do to some weird interaction with other code or data anomaly doesn't run properly. To me, that's not a bug but a poor specification; or simply one of those unforeseen events that happen in any project.

Given his statement "Developers are always fine with it until we get toward the end of a project and the customer is complaining about bugs." leads me to believe that there is more than just poor programming at play here; a combination of how specifications are written, testing practices, poor documentation of existing systems and data structures, and changing requirements seems to me to be a logical explanation for issues that arise. It sounds like he is paying by the hour and iif so the programmers concerns are valid. If he can't pay what it takes to get a full time hire with the needed skills he is better off biting the bullet, raising his prices,and paying developers to fix bugs instead of getting someone who cannot do the job to his expectations. He could go to a deliverables model - pay for a specific functional code, but that won't really solve his problem - expecting perfect code at a cut rate - and probably cost more. I know if I get requests for a fixed price I triple my estimate to cover any unexpected issues that may arise; and if they don't I pocket the bonus. I also get a very specific contract detailing exactly what they get to protect myself from schedule delays, changing requirements, etc.

Re: Have u thought about..

[Registered Coward v2]

I do actually expect all work I pay for to be "bug free" I recently had an aftermarket bed liner put in my truck, and it came back with a bug: it was crooked. I took it back and demanded they make it right for free. And you know what happened? They fixed it for free. Everyone makes mistakes, but when the product makes it to the customer it had better be right. Why are programmers exempt from workmanship standards?

There is a difference from what is a reasonable standard that is generally accepted for a product and perfection. A crooked bed liner is clearly not normal, but if you expected every seam to be within .0000001 of an inch then you would be beyond the bounds or reasonable and customary. Programers aren't exempt, but workmanship standards do not mean 100% bug free code; especially since every situation can not be anticipated and all bugs discovered and fixed.

Re: Have u thought about..

[Shadowmist]

My code is not guaranteed indefinitely. Any bugs which appear after the contract is expired can be fixed under another contract if I agree to fix them. I am certainly under no obligation to do that later work at all and especially not for free.

Interesting that you're not prepared to guarantee your work. It would make me wary of contracting you as it places the onus on me to ensure that I've throughly tested your code rather than on you. Is this common practice?

All guarantees have limits. With cars, it's a set number of miles or months, whatever is reached first. With most products it's 30 days, or not at all. When you devalue labor by eliminating in house staff to penny ante it to outside contractors, there are going to be consequences. You're not keeping a contractor on retainer, you're going to have to have reasonable limitations on your expectations.

Re: Have u thought about..

[HungryHobo]

It's common practice in every real field.

if you hire a construction firm to build an office block you go in, or hire someone else to go in and create a list of snags or problems which they can find and the firm you hired to build the block fix them. once you've signed off it doesn't matter if you didn't notice that one floor was missing all it's water pipes. (real example)

you've inspected the job and signed it off. If you want a change or find a problem after that you have to hire them or someone else to do it.

unless of course you specify it in the contract. but that'll likely cost you extra.

Re: Have u thought about..

[Dr. Sheldon Cooper]

I have had the pleasure of being the project manager on several fairly large software projects during my career. These projects were finished on time and to spec. Everything the customer asked for in the agreed-upon scope worked. Everyone was happy...

However, as a precaution, I ALWAYS insist on putting a post-release support agreement in place at the start of the project. This lets the customer know that if problems arise, they will be addressed and fixed if at all possible, and it gets the developer in the mindset of providing continuing support after release. This has worked amazingly well for everyone involved. The customer feels secure and the developer does not have to work for free.

Re: Have u thought about..

[sycodon]

I do not pay for bugs.

This guy is a prick.

And you are not far behind.

How many times has Microsoft broken everyone's code with one of their updates?
How many times has someone's code been broken by some other app dicking around with things it shouldn't?
How many times has some idiot administrator broken code by fucking with security?
How many times has someone's code been broken by a DBA changing shit in the database?
How many times has someone's code been broken by the user jacking around with it and deleting stuff they shouldn't be messing with?
How many times has someone's code been broken by viruses, malware, etc?
How many times has someone's code been broken because the user changes the OS?
How many times has code been called broken because the user didn't know exactly what they needed and genius here didn't bother to catch it?

You can write perfect code and there are legions of ways it can be "broke" by others in ways you can't and/or shouldn't anticipate.

Re: Have u thought about..

[beelsebob]

You got modded down, but you're absolutely right. If he could reasonably make money by actually doing the work himself, he would be doing that. Clearly he can make more money by getting someone naïve to do the work for him and then making the profit himself. What's happening here is that the naïve people have stopped being so naïve and he's having to move back to the other business model to correct for it.

Wake up

[Cenan]

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

[KraxxxZ01]

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

Re:Wake up

[complete loony]

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

[jellomizer]

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

[BasilBrush]

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

[CptNerd]

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

[Bearhouse]

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

[Cenan]

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

[Cenan]

Well, a little rude, but not totally wrong.

Yeah, although that was not by accident at all. Somehow people like the AC who asked the question pushes my buttons. The whole story reeks of a lack of understanding of how software development works, yet it is somehow the fault of somebody else. God forbid he looks at his own process with an eye towards making improvements.

Some /.-ers see through the smoke and recognize that "empathy for developers" is a marketing stunt because he knows /. - and knows that half the audience is going to eat that right up.

When asking questions at least be honest and, as with all homework, show the work you have so far. Setting himself up to be some kind of hero defeats the purpose. If he's such a God among mortals, why is he having these basic problems at all?

Completion Bonus

[CaptQuark]

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.

Good luck with that!

[Kwyj1b0]

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

Pay for the tests

[mangu]

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.

Not in touch with reality

[eennaarbrak]

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.

Sigh... repeat after me

[mwvdlee]

Code is never 100% bug free, no matter how smart the programmer, how well tested the code and how many million hours it's been running without any problem.
The only type of developer willing to agree to a "fix-bugs-for-free" contract is one who is either (A) stupid of (B) lying.

Thoughts from an Analyst

[realsilly]

I am an analyst and I often write requirements, test code and write user documentation. I've been in the industry for 20+ years. I have never met a single developer who doesn't have bugs in code. I've read some of the posts in this thread and many of you are comparing building contractors to software developer contractors and I honestly think you're comparing apples to oranges.

I don't know what the small business owner is making but I believe, to some degree his demands are unreasonable. When a contractor comes into your house to install an item, there are a limited number of ways in which that contractor can perform the tasks to complete the job. If that contractor must deviate from standard specs they run the possibility of having issues with the installed item. And under their contract, under normal conditions, they have limited liability to correct the issues after installation. If the house has a non-standard configuration, and the contractor must fit a square peg into a round hole, this is usually discussed before the work is performed and agreements are made. However, it happens all the time where a contractor faces a hidden issue in their goal to complete the task correctly without issue.

From that description comparing a building contractor to a software developer contractor is feasible. But code is different. With code there are several ways to skin a cat and depending on how rigid the specifications are can influence the amount of bugs that can be created. As good as I would like to think I am in writing requirements there are always hidden requirements that can't be considered until a software developer gets into the process of writing the code. The small business owner claims to have written the specifications, and I don't believe he has developer experience, and to write a chunk of code to capture data in one place may open several doors within the product on how to handle that captured data. Unless the specifications are that meticulous there will be bugs. My question would be, have you hired a tester? Just because requirement 1 says "capture data", and requirement 2 says "store data", where is the requirement on the length and type of data to store? Boom, bug. If specifications don't get down to that level of detail everywhere, there will be bugs. And if your specifications are that meticulous, then how much time is over used up front.

On top of that, you're requesting that a developer be able to write in multiple coding languages. How much would you pay an interpreter to speak five spoken languages? A lot of money, software developers who can write in multiple coding languages and are proficient in all of them don't come cheap. Specifications to interpret one to one from one language to the next.

I'd say the following:
1. raise your prices you're charging your customer
2. insist on a very small subset of development languages
3. hire a full time employee and find someone who cares about success in your company
4. perks, perks, perks
5. hire interns for testing
6. Most important, demand excellence, but be realistic.

What's missing from the question

[MadKeithV]

What is missing from the question, and being filled in by expectation by many of the previous posters to this story, is how you define your bugs that you want your developers to fix for free.

If you define a "bug" as an operation that clearly and objectively fails to meet the expectations set out explicitly in your requirements and specs, then you are in the clear. Basically the situation where your specs state: "When presented with A and B the software will do C", and the software does D. Not conforming to the explicit spec is a clear defect that the developer should have caught.

If the "bug" is actually "something the client didn't like in your implementation", then tough. The software performs to spec. It doesn't matter how obvious it seems to you or your client now that you see the software that this isn't desired behavior - the desired behavior was not described in the spec and not included in the quote you got. You made an error of omission in your spec - it's your error to fix, not the developer's.
If you think through on this path you will start to realize that writing a totally air-tight spec is outside of your ability. Stop trying. You aren't that good. No, you really aren't. There are going to be areas where you, the client, and the developer have very different opinions on the severity or "correctness" of certain behaviors not specified in your spec.

Finally, realize that you are actually taking a passively antagonistic stance to your developers. A priori you are assuming that they will deliberately add bugs to inflate their income. This is bullshit. Contract developers are smart people. They know "recurring business". These guys may be *smarter than you*. The good ones are not out to get you, they want you to be happy with their services so you come back the next time. So drop the antagonism and work with them on the actual issues. Meeting each other at a reasonable half way point works wonders in any relationship, including professional ones.