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

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

[gmclapp]

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?

Re: Have u thought about..

[Anonymous Coward]

Reductio ad absurdam, eh? The reason "programmers [are] exempt from workmanship standards" is, ultimately, the Halting Problem. When you understand the Halting Problem, and you understand what that has to do with bugs, THEN you will have a right to critique programming as a profession.

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

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

Re: Have u thought about..

[ArhcAngel]

You said you were a programmer once. What made you leave the field? As a "former" programmer myself I left because of the pressures that came from employers who demanded that a feature in the newly released competitor product A must be implemented in our product by the end of the week or the company would fold. Customers who demanded a feature or functionality they never requested but demand that they did be added or they sheepishly request new features at the end of the project and want it added gratis. Add to that a programming landscape that shifted so frequently it was impossible to stay on top of the language du jour. I used to love to program but after doing it for a living for a few years I find it hard to this day to even look at code without painful memories.

As for the question at hand, If you can't pay $100K or more annually I seriously doubt you will find a programmer versed in multiple high profile languages that isn't already self-employed and doing quite well for themselves. You might want to consider a business partnership where you run the business and project side of things.

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

[merovingi]

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

Re:Wake up

[KraxxxZ01]

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

Re:Wake up

[Joce640k]

if your specs were so masterfully created there would be no 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

[Cenan]

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

[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

[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

[Kjella]

As a general rule there's two kinds of contracts, fixed bid and time&material. The former usually means a predefined scope at a fixed price, formal change orders and bug fixes are usually free within a given testing period. The other is basically "do whatever I say" and yes I will, but I don't own the specification and I'm not making any sign-offs on what I'll deliver - I just work hours for you. You get various forms of hybrids - I consider agile one of them - but that's the archetypes. I've coded off "specifications" that were a yellow post-it note, rushed it to production with hardly any testing or documentation and if it works for them it works for me. If you're overall not happy with my work stop the contract, but I charge you every hour even when I'm bug fixing my own work.

It sounds to me like you're asking for the best of both worlds, contractors that'll work regular hours during most of the project and do bug fixes for free at the end. That is going to be trouble, every time. Hell, when you say "programming project manager" I'm starting to think they're not even in full control of the code, far less the spec. Contractors tend to love repeat business, have you them coming back for more? No? Probably because they feel railroaded by the process. Do your contractors ever reject your specs? Can they reject your specs? Or are you just telling them these are the specs and I'm saying they're good enough, get to work? What about when things undoubtedly come up, is there a formal change process or you just improving or amending the spec?

Good enough to work by and good enough to sign off on are two entirely different things, try doing a proper fixed bid project and I think you'll find out.

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?

Hiring?

[Anonymous Coward]

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

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

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.

Forget it

[Opportunist]

You're looking for someone who is incredibly good (able to offer a wide variety of programming languages, good enough to not create any bugs, anticipate them and/or find them very quickly), that is essentially someone who could pick and choose his job, but pay him like some intern.

Would you do it?

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.

Re:Pay for the tests

[Anonymous Coward]

That's test-driven development. Write the tests first, then write code which satisfies the tests. Done.

It doesn't work like that, because there is no way to completely specify a non-trivial program through tests. For (a trivial) example, suppose I specify that I want a program which takes two numbers, adds them and outputs the result. For acceptance, the program shall be tested with the following test cases: "1+1=2", "2+4=6", "100000+234=10234". Now if you're a good programmer, you're going to write the program such that it takes any two numbers (positive, negative, large, small, integer, non-integer) and adds them arithmetically. That program would surely pass the acceptance tests. A lazy programmer might just write a program which looks up the result in a table and consequently satisfies only the acceptance test but is otherwise useless. Note that the specification was vague and didn't include any information about the types of numbers you want to add. Was it wrong not to include imaginary numbers? What is the input format for floating point numbers? Decimal comma or decimal dot? E-Notation? What about rounding and input and output ranges?

Program specification is like writing laws. It's not context-free (in the real world sense, not in the computer language sense). We all make assumptions about the scope of the specifications. Almost always a programmer can only decide what the actual requirements are by making use of extensive application knowledge.

UAT ?

[mrmangosir559]

Sounds like to me there is no UAT going on. Old method but, Development->UAT->Product, should be the most basic method. Sounds like you are handing over the software without any sign off from the customer. If they are signing it off, are you getting them to test it first? As part of your contract with the developer, you should be making sure the developer is aware of this process. That "within reason", the customer should be testing the software according to your specification. Any bugs can be returned to the developer. Once it meets the specification, then the customer signs it off. The customer is then aware, any issues after that period they pay and the developer knows after that period they get payed. Having an employed developer, means you have an overhead if you have no business coming in.

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.

Subby isn't as good as he/she thinks.

[mcmonkey]

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.

There is no excuse for developers not testing their code, because you shouldn't expect that to be the final testing. That's your job. I think the analogy someone else posted above is apt, programmers need testers just as writers need editors.

What the developers send you should be reasonably complete, as in not a first draft. But it shouldn't be assumed to be a finished product ready to pass to the customer.

So why are customers complaining about bugs? If you write "excellent product specs," "provide bug tracking & source control," and "provide detailed, reproducible bug reports," why are you passing along buggy code to your customers? Why aren't you doing your job as a project manager?

It sounds like you're not sticking to your product specs, not using the bug tracking & source control, not reading those bug reports.

That you've been moved to ask /. leads me to think this is a recurring problem. Remember Subby, the common aspect of all your failed relationships is you.