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?"
Sounds like a partnership (Score:2, Interesting)
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.
Completion Bonus (Score:5, Interesting)
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:Wake up (Score:1, Interesting)
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:Have u thought about.. (Score:5, Interesting)
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:Wake up (Score:4, Interesting)
>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 (Score:5, Interesting)
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: Have u thought about.. (Score:5, Interesting)
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.. (Score:2, Interesting)
Why are programmers exempt from workmanship standards?
Because almost nobody wants to pay what it would cost to write programs that are mostly bug free. Mind you, there are applications where correctness is valued high enough to invest the time and money to get it right. Most people have decided that it's not worth the wait or price though and prefer to live with functionality now and updates later.
Re:Stop being cheap. (Score:4, Interesting)
The specs are never as good as the spec writers think they are.
I've been a developer (contractor and employee) for nearly 20 years and have never seen specs that clearly defined everything. In any project of notable size, there are always huge portions of "it's obvious what I want," often with the UI. Spec writers are generally terrible at thinking about "edge case" behavior, focussing on the "normal flow" and trivializing the "alternate flows."
Why do you think the OP always has battles at the end of the project?.
Given the spec is incomplete, and your experience, wouldn't best practice be to analyse the requirements at the start and identify those edge cases and get decisions on them before starting.
Whilst building out large systems I have written functional specification and detailed designs for clients that, in the end, stated absolutely what would be done and how each interface would look and perform. This made implementation simpler, because all of the decisions where made up front, and gave something to test against when completed.
Way back in the early '80s when I got my degree the thing that was placed into our heads was to spend 90% of the time designing, 5% coding, and 5% testing. These days we seem to dive into coding way too early.
Re: Have u thought about.. (Score:5, Interesting)
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.
I hear you (Score:4, Interesting)
I'm in the exact other boat, so I can see the same problem from the other side. I run a web development business, I don't write specs, I do everything in my languages of choice, I also market being able to handle any technical project for my clients. In my case, however, I specifically don't charge them for bugs. Everything's either project-based pricing or feature-based pricing. Bug fixing, cosmetic alterations, and cursory data field/presentation changing is free. I do all of that in order to justify not writing specs in the first place -- because I'm not you.
I tried paying contractors to work for me. I tried paying employees to work for me. And even paying them proper salaries I got the same results as you're getting from contractors. As employees, instead of running away, the work effort got sloppier and sloppier as bugs and client changes were hacks ontop of hacks. Their speed dropped to nill, and it basically sucked me dry to the point where I could easily lose all of my personal take-out when bug repairs ran longer and longer. And you can't tell a client, especially before they've signed off on a project, that a huge expense is to fix bugs that don't exist yet in something that should be written properly the first time, especially in their minds.
So my advice to you is going to be different. My advice to you is to find contractor developers like myself who do fix bugs for free. But I'm going to tell you that the only way to make that fair to them is to let those developers choose the tools -- i.e. the languages they use. I've spent two decades building up my own tools, to the point where now I can easily handle bugs and after-the-fact client changes so it doesn't cost me anything to fix bugs -- and if you're telling me that you'll produce the test case, then you've saved me 80% of the work. And if I know that you're the one doing it, then I can upgrade my platform to show me exactly what you tested, which will ultimately point me to the very code itself, and that's a total of 90% of the work 90% of the time.
Find the right contractor who knows how to appreciate your policy. I can guarantee he exists, because I'm one of them. There must be others.