Ask Slashdot: Moving From Contract Developers To Hiring One In-House? 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?"
Re:Wake up (Score:4, Informative)
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.
Pay for the tests (Score:5, Informative)
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:Wake up (Score:4, Informative)
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.
To Pay or Not To Pay, That is the Question (Score:4, Informative)
However, even though I am fixing bugs for "free" they really aren't free. The extra time it takes to fix bugs is simply factored into the initial contract costs. If the contract payment is too low, nothing is forcing you as a freelancer to accept it. You simply take those contracts which have a payment requisite to the amount of time you think it will take to make the software and fix its bugs relative to the complexity of the software you are creating.
I mean you can say "I don't pay for bugs," but really everyone is paying for bugs whether they think they are or not.
Re: Have u thought about.. (Score:5, Informative)
"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.
Why do the bugs only surface toward the end? (Score:4, Informative)
My first thought as I was reading the summary is "why are the bugs only being highlighted at the end of the project?".
Granted, that is when the users have something approaching a "complete" product to work with so that is where they will do most of their testing... wait, have I just answered my own question?? It seems I have, yes.
Welcome to the wonderful world of the project manager and analyst - if the client is coming with bug reports, there are 3 potential areas where someone screwed up - either the client explained it badly (in which case, it is not a bug as such, it is a functional change - paid work), or you did not do as good a job as you should have of writing the spec (in which case, in my opinion, you should eat the cost and learn from the mistake), or the developer botched the implementation of your spec (in an ideal world, the developer *should* fix that, as they caused the problem).
If the client or you screw up, just about the only way to catch that is during a user acceptance test. Determining whether the screw-up is yours or the client's comes down to a review of your spec and needs some honest appraisal by you - if the spec is unambiguous and the product does what the spec says, and the client has signed off on the spec, then it is their fault. If the spec is ambiguous and open to interpretation (typically this is going to be when the spec matches what the user wants, and what the product does, but the product and the user's expectations do not match), then you have the fault. Yes, it is incredibly hard to write clear, unambiguous specs and then get a client to read through them and understand them... but in that case the spec is a bit like a EULA - the user does not have to read and understand them, they just have to sign on the dotted line to say "the spec matches what I want".
If the dev screws up, getting them to hold their hand up and admit to the fault and fix it is hard, as you have found - why work for free when you can work for money - but if you structure the contract correctly, with a completion bonus that they get when the client takes delivery, then you have some kind of hold over them. For example, a basic wage of $60k/year pro rata with $40k/year pro rata paid after sign-off. Some/most contractors will be put off by that, and they are typically the ones who will cut and run at the first mention of "bug" and "free". But the ones who are willing to take that on will probably be more conscientious in terms of self-testing, unit testing, analysis and possibly querying the spec, because if they can get it right first time, they get the bonus without doing any extra work...
As for the other side - getting the users to test and validate earlier in the process, for that you need to deliver functional prototypes early in the process and implement some manner of testing window - most of the companies I have worked for as a PM/analyst have contract clauses that give clients a 30-60 day window from delivery of a new version of an application to report bugs as bugs - after that, any errors are categorized as billable change requests, so the client has both incentive and responsibility to perform testing of their own.
It does mean that you get to have some tough conversations with a client because they are reporting a "bug" after 5 minutes of use, 6 months after you delivered the application, and if you want to be flexible and client-focussed, you can look at whether that bug should have been caught by in-house testing to confirm compliance with your spec.
Lastly, when you find a couple of good contractors who are able to write good code and who take enough pride in teh quality of their work that they are willing to work on fixing bugs in their code (they do exist, honestly, they are about twice as common as unicorns, and are sighted more often than flying pigs), either offer them a permanent position, marry them off to your sister so that you can keep track of them, or tell them that they do such good work you will want to call them back next time you get a juicy and interesting project.
ok, maybe I am a bit too naive for this job, but I have been working as an analyst/PM/IT implementation consultant in the banking and finance industry for the last 10 years.
What's missing from the question (Score:5, Informative)
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.
Re: Have u thought about.. (Score:4, Informative)
This entire discussion has either misused the term "contracting", or deliberately glossed over it (by which I don't mean to accuse you specifically, the whole thread has that problem).
When I work under salary, I get paid for projects (along with a certain amount of "keeping the lights on" shit-work, of course). I work unpaid OT if necessary, and cut out early when ahead of schedule. I generally expect (and get) a very flexible schedule so long as I get my tasks done.
When I work as a contractor (and yes, I do both), I get paid for my time. I'll give a good estimate of how long it will take me, but if we run over, you keep paying. Simple as that. Yes, that could potentially lead to abuses by unscrupulous programmers - And they wouldn't get any repeat work for pulling crap like that. Just part of the game: Find a few that work well with/for you, and make them happy enough to stick around.
To address the FP post, though, you can't have it both ways. Sure, you sound like great boss in good times, then a bastard at the least pleasant part of the project. All code has bugs, period. Usually the major ones come from ambiguities in the specs; but even assuming a perfect spec, All code (still) has bugs, period.
If you don't budget some percentage of the total project resources to identifying and correcting those bugs, you have failed to properly manage the project. Instead, you have committed the PM version of the classic mathematician's proof-joke, "We start by assuming all cats as perfect black-body spheres in a frictionless environment...".