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

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

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

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

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

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

[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

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

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