Forgot your password?
typodupeerror
Bug Businesses Programming Software

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

Posted by Soulskill
from the wipe-his-brain-and-download-stack-overflow-into-it dept.
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?"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by woja (633458) on Wednesday May 22, 2013 @05:22AM (#43791641)
    Hiring contractors you can trust and pay them to fix bugs?
    • by Anonymous Coward on Wednesday May 22, 2013 @05:32AM (#43791697)

      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.

      • by Half-pint HAL (718102) on Wednesday May 22, 2013 @05:38AM (#43791721)

        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.

        • by e r (2847683) on Wednesday May 22, 2013 @05:47AM (#43791769)
          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.
          • by Half-pint HAL (718102) on Wednesday May 22, 2013 @06:00AM (#43791835)

            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.

            • by XopherMV (575514) * on Wednesday May 22, 2013 @06:46AM (#43792013) Journal
              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.
              • by Registered Coward v2 (447531) on Wednesday May 22, 2013 @07:43AM (#43792285)

                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.

                • by Joce640k (829181)

                  There's bugs where a program doesn't follow the specs (logic bugs) and there's bugs where the program crashes because you didn't check the return value of malloc() (or whatever).

                  I could argue that both of those are negligence on the part of the programmer, but at the end of the day we're arguing over whether there's such a thing as perfect software or not. Empirical evidence suggests there isn't (at least not at prices that normal people are willing to pay).

                  The only way to avoid conflict is to pre-agree a p

                • by Belial6 (794905)
                  The hourly vs. deliverable is likely the biggest conflict he is facing. I have found that virtually 100% of the time customers want hourly if the project is done early and by deliverable if it runs late. This problem gets way worse when the customer is another contractor sub-contracting out their own work. The fact that he didn't mention whether his rates are hourly or by deliverable implies that he is playing this game.
            • by Xest (935314) on Wednesday May 22, 2013 @07:13AM (#43792137)

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

              • by DarkOx (621550)

                I think it depends what the arrangement is. If you hire someone to create deliverable X with defined specs for $Y then if they take the contract they need to provide deliverable X to spec no matter how long it takes them; or you don't pay.

                Its up to the contracted not to accept a job where the specs are inadequate. If the job is going to be big enough that its worth while maybe you provide some good customer service and help write clear specs; that everyone can understand and agree to.

                On the other hand lot

            • by pmontra (738736)
              There are "hard" bugs (let's call them so) as in "a +=2 instead of a += 3" and there are "soft" bugs as in "neither the customer nor us thought about that (possibly very complicated) combination of inputs and internal state, and our code doesn't yield the right result". That's the "what do we do when..." question that many times developers ask to designers. Unfortunately hard bugs are relatively easy to find with test suites and code reviews but soft bugs can accumulate unnoticed until the end of the projec
            • by Xyrus (755017)

              When I was at school, my parents hired a contractor to build an extension to the house....

              Stop. Just stop.

              Programming is not the same thing as building house. It's a popular, but ludicrous analogy. Even a small program can have billions of different possible execution paths. In fact, if your code has 30 if statements you're already over a billion execution paths (2^30). Why do you think it's so damn hard to make bug proof code? You can have unit tests, integration tests, a dedicated test team and still miss bugs. Even years after the product is finished bugs can still be found by ingenious users

            • by ArhcAngel (247594) on Wednesday May 22, 2013 @10:47AM (#43794027)
              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.
          • by gnasher719 (869701) on Wednesday May 22, 2013 @06:25AM (#43791919)

            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.

        • by chrismcb (983081)

          This man's view of bugs is the right one,

          Only if the person he is hiring is PERFECT. I don't know any human being that is perfect.
          But as I understand it, he is paying the devs to find their own bugs. But if someone else finds the bug, he won't pay for it.

  • Wake up (Score:5, Insightful)

    by Cenan (1892902) on Wednesday May 22, 2013 @05:22AM (#43791645)

    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: (Score:3, Insightful)

      by merovingi (1632365)
      It's good to vent out our frustrations and anger on others especially when they are asking for ideas.
      • Re:Wake up (Score:5, Insightful)

        by jellomizer (103300) on Wednesday May 22, 2013 @05:57AM (#43791819)

        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 (Score:5, Insightful)

      by KraxxxZ01 (2445360) on Wednesday May 22, 2013 @05:29AM (#43791679)
      Signed. Also "empathy for developers" and " I do not pay for bugs" does not compute.
      • by neoshroom (324937) on Wednesday May 22, 2013 @07:04AM (#43792085)
        Really is all depends on how he pays, doesn't it? I am a contract freelance software developer and I use the exact same policy he does with clients.

        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:Wake up (Score:4, Insightful)

      by Joce640k (829181) on Wednesday May 22, 2013 @05:30AM (#43791689) Homepage

      if your specs were so masterfully created there would be no bugs.

      does not compute.

    • Re: (Score:2, Offtopic)

      by Half-pint HAL (718102)

      Oh shut the fuck up, if your specs were so masterfully created there would be no bugs.

      If your post wer so well ritten their wood bee know mis-takes in my response.

    • Re:Wake up (Score:5, Insightful)

      by complete loony (663508) <Jeremy.Lakeman@gm a i l . c om> on Wednesday May 22, 2013 @05:45AM (#43791763)

      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 (Score:4, Informative)

      by jellomizer (103300) on Wednesday May 22, 2013 @05:50AM (#43791789)

      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.

    • Re:Wake up (Score:4, Interesting)

      by ShakaUVM (157947) on Wednesday May 22, 2013 @05:55AM (#43791813) Homepage Journal

      >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:4, Informative)

        by Cenan (1892902) on Wednesday May 22, 2013 @06:37AM (#43791969)

        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.

    • Re:Wake up (Score:5, Interesting)

      by Bearhouse (1034238) on Wednesday May 22, 2013 @06:19AM (#43791897)

      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 (Score:5, Insightful)

        by Cenan (1892902) on Wednesday May 22, 2013 @06:58AM (#43792059)

        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?

    • I am a contract software developer and have this exact same same policy myself. That is, when I get a client I ask for detailed specifications and we put them on paper. Then I go to work on the project. If when done they want a feature that isn't in the spec, we create a new milestone and they pay for it. If they find a bug and want it fixed, I fix it for free. It's just another way of saying "I guarantee my work."

      There is no possible way that masterful specs can eliminate all bugs. In fact, I'm gu
    • Re:Wake up (Score:4, Insightful)

      by Kjella (173770) on Wednesday May 22, 2013 @06:44AM (#43792001) Homepage

      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.

  • by Anonymous Coward

    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.

  • Hiring? (Score:2, Insightful)

    by Anonymous Coward

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

  • Completion Bonus (Score:5, Interesting)

    by CaptQuark (2706165) on Wednesday May 22, 2013 @05:29AM (#43791675)
    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.
  • by Kwyj1b0 (2757125) on Wednesday May 22, 2013 @05:29AM (#43791681)

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

  • 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

    hardly true. If you want 100% bug free code then expect the devs to take twice as long to provide the solution (and that's being optimistic). If you don't want the tested-to-death solution, and want to take a pragmatic approach where you assume some bugs will fall through the dev process, then you'll get the solution quicker overall. (obviously there are some devs to whom a bug is a way of life, I assume you will not hire them again)

    BTW good for you, not wanting devs to work weekends. Do they get national h

  • If you are going to be wishing for things like the perfect employee (knows lots of languages, is proficient in all of them, is cheap) then you might as well just wish for peace on earth, good will to mankind .. and a pony.

    And while you are doing that, take a look a what people with experience in only a few areas are being paid, and then factor in some overheads. Or in other words, is that $100k as salary to them and you will have a bunch of overheads to carry, or is the $100k including overheads? Because

  • by HungryHobo (1314109) on Wednesday May 22, 2013 @05:54AM (#43791809)

    There's no such thing as non trivial bug free code. only code which has not been tested in enough circumstances.

    No. really. Even limiting it to just security related bugs with an author who put an insane amount of work into making it bug free who knew exactly what he wanted with no communication with a client bugs still turn up when code is exposed to the real world.

    http://en.wikipedia.org/wiki/Qmail [wikipedia.org]

    Totally bug free code is insanely expensive to write in even small amounts so you're basically having the developers spin the wheel, if your clients do massive amounts of testing they end up working for months unpaid. if they do little testing and can live with lots of little bugs then the Dev gets a good deal.

    Here's a sane solution to your problem: pay for bug fixing.

  • by joe user jr (230757) on Wednesday May 22, 2013 @06:04AM (#43791849)

    "with the specifications I write there is no excuse for not testing their code" - so why don't you test their code, then? (If you can't do this yourself, hire QA.) Regard the contract as complete when all your tests pass (note: *your* tests!).

    If bugs are found after the project is complete, it is because the test coverage was incomplete, or QA failed, and you should be happy to take responsibility for having them resolved (including payment if necessary.)

  • Writing very good specs means having a good understanding of the business needs for that project.
    Both getting to understand the needs and writing great specs take a lot of your time and effort.

    So perhaps you should learn how to code yourself. Spend just as much time understanding the business problem, then write the specs in a brief way (you obviously know what you need to do anyway), then code it yourself. No miscommunication possible. Any bugs are yours and yours alone.

    I'm pretty sure you will gain a lot

  • I am a developer who also has some experience paying other developers for a project. I do not agree with some of the criticism you are getting. If you say up front you won't pay for bugs then the developer should not accept the work if they don't want to work under those conditions. It is easy to say "all code has bugs" but it is also true that cleaner and well thought out code will have less bugs and the more unit testing that is done on code the less bugs it will have. Why reward sloppy behavior? Nothi
  • In your contract, you should have acceptance tests specified. The contractor that hires you should test and approve the product. If it's not what they want, contains bugs, or is not as specified by them, they should not accept. When they have accepted the product, they should pay for bugs. You should agree about this before starting.

    For now, fix those bugs, and think of it as a good and valuable lesson.

  • by eennaarbrak (1089393) on Wednesday May 22, 2013 @06:11AM (#43791877)

    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.

    • by CptNerd (455084)

      No matter how thoroughly tested software is, there will be places where it breaks in production, through no fault of the developers and testers. If you don't believe this, you haven't worked on enough systems, or they haven't been complicated enough.

  • My suggestion is you look at your current list of contractors, order them by how well they cooperate with you, and make the "best" an offer. You won't find anybody perfect, better the developer you know than the genius you don't!

  • Forget it (Score:4, Insightful)

    by Opportunist (166417) on Wednesday May 22, 2013 @06:50AM (#43792027)

    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?

  • by mwvdlee (775178) on Wednesday May 22, 2013 @06:51AM (#43792035) Homepage

    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.

  • If you want an excellent engineer, you need to pay at least reasonable.

  • by Afty0r (263037) on Wednesday May 22, 2013 @06:52AM (#43792039) Homepage

    Then it sounds like you will need to give some equity in your business away.

    Or, consider this - why are you allowing the same guys writing the software to be responsible for testing it? If you genuinely write good specs you should be able to find someone who will write automated testing (and/or engage in manual testing) to meet your spec and apply it against the software provided by the contractor. This should eliminate a very large number of potential bugs. If your specs are good enough you could even offshore this fairly easily - it's very simple work.

  • by gr8_phk (621180) on Wednesday May 22, 2013 @07:01AM (#43792071)

    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.

    Anyone who says they write perfect specs or perfect code, or perfect anything is full of shit. Even if YOU write perfect specs, they're based on customer requirements and those are always incomplete. Customers do not have requirements, they have problems, and it's our job to devise solutions to those problems. Even if code is written bug-free the customer will not know exactly how it should work until you give them something to critique. Then they ask for changes - this is called a requirement change or clarification, not a bug, and not the developers fault. I'm sure your developers create bugs too, but I'm certain they're not the only cause.

    BTW, my subject line applies to developers too.

  • by RobinH (124750) on Wednesday May 22, 2013 @07:12AM (#43792125) Homepage
    So you're paying these developers some kind of contract rate "by the hour" but you then want to impose a fixed scope and hold them to it later? I mean if you're providing them with a complete (perfect) functional spec, then ask them to bid on it as a fixed price, make sure they include a 1 year warranty for any software defects, and then by contract they have to fix the bugs. Sounds like you just want the benefits of paying by the hour without any of the negatives.
  • by Stolpskott (2422670) on Wednesday May 22, 2013 @07:46AM (#43792303)

    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.

  • by bugnuts (94678) on Wednesday May 22, 2013 @08:00AM (#43792389) Journal

    Instead of an end product coder, hire a unit tester. Hand him the specs that you send out, and have him code unit tests for all input categories of the different modules, and check results and fail modes. Hell, have him send out these tests as he finishes, so that the contractors can use them, too.

    If the unit tests are correct and the software is failing, don't send out paychecks until it passes. Getting the test suite running may take a week or two once the code is delivered, so you might be a little later than you usually are. But you contracted for working code, and the easiest way to verify it's correct is to pass a test suite. Once it passes that, you'll know that it passed YOUR specs. At this point, if there are bugs despite meeting the specs, it's your fault.

    • by bmacs27 (1314285)
      This is what I was going to say. First of all, testers cost less money. Second of all, testers keep you from being as bad as the developer by sending customers a product they subsequently need to debug. Third of all, testers would identify contractual culpability with respect to failing software. You should expect to pay developers to fix bugs you did not catch in testing. If you didn't catch them, and were satisfied with the result, you shouldn't expect them to catch them either. They are right to ex
  • by bradley13 (1118935) on Wednesday May 22, 2013 @08:13AM (#43792471) Homepage

    What is your agreement with the contractors? From your statement that you "pay on time" I have the feeling that this is where your problem is.

    If you have agreed: "I will pay you $x per hour of work", then you are paying for their time. If bugs need fixed, you need to pay for some more of their time.

    On the other hand, if you say "I will pay you $x if you write a program that meets this specification", then you simply do not pay until you have such a program. If it's a big project, it may make sense to define some intermediate milestones, where the programmer receives partial payment. However, a large portion of the payment (at least 1/3) should be released only after the program has passed acceptance tests.

    A contractor ought to charge you slightly more for the second option, because the contractor is carrying the risk.

  • by Shadowmist (57488) on Wednesday May 22, 2013 @08:20AM (#43792527)

    The OP essentially wants to be able to act like a software development company on the cheap. A software development company has it's own full time staff to develop code and budgets time for things such as beta testing and fixing the INEVITABLE bugs that come up, especially for major pieces of software. This of course is not cheap, you're paying salaries and benefits to maintain such resources.

    If you're going to try to do this on the cheap by outsourcing it, then you're going to have to admit that you're not a developing house, you're just a shell game trying to hide the fact that you're not the publishing house you're making yourself out to be to your customers.

  • UAT ? (Score:3, Insightful)

    by Mr Mango (2929691) on Wednesday May 22, 2013 @08:24AM (#43792557)
    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.
  • by realsilly (186931) on Wednesday May 22, 2013 @08:43AM (#43792719)

    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.

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

      A friend of mine built a house. One contractor drove a nail through a water pipe. Well, mistakes happen. He then wrapped a plastic bag over the hole and plastered over it. Everything actually looked fine for a month (must have used an excellent plastic bag) until a dark spot developed and became bigger and bigger.

      I must laugh when people say there are fewer bugs in different professions.

  • by MadKeithV (102058) on Wednesday May 22, 2013 @09:09AM (#43792959)
    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.
  • If you can't afford to pay someone what it costs to do the job right, then you can't afford to be in the business you're in. You can do it for a while, until you build up a reputation for overpromising and underdelivering. You should focus on work you can afford to do.

  • by satch89450 (186046) on Wednesday May 22, 2013 @09:33AM (#43793167) Homepage

    "I write excellent product specs" -- are these product specifications sufficiently detailed to have a consulting Software Quality Assurance person be able to test each feature of the product? Sufficiently detailed so the multiple people you hire can seamlessly do integration testing? What scaffolding do you provide for each of the developers? Do you have the same "source control" of your specifications as you do for the code generated from them? How do you handle "feature creep"?

    "Bug tracking and source control" -- Do you have staff or contractors who confirm the bugs? And how do you handle regression testing during development and subsequent maintenance? How about code reviews? Who handles customer service queries?

    "Empathy for developers" -- demanding bug-free code without the tools and processes to give the contract developers a fighting chance? How well do you anticipate corner cases in your products, so you can include them in your specification? What practices do you insist on to catch bugs early in the product development cycle?

    "...hire someone full-time...know a lot of languages and be proficient in all of them...can't afford to pay someone $100k/year" -- Sounds like a version of the Universal Specification: "I want everything, now for, $1.98." As for pay, that one is easy: make him a partner, and he earns from the bottom line just like you do. You will probably have to take a bit of a pay cut to attract what is essentially a do-everything maintenance programmer, not exactly the career track that anyone with the type of experience you are looking for would choose. Have you looked at the pool of experienced programmers? There are quite a few who have been put out to pasture because they don't have the "zing" in their resume that most [In]Homan Resource people look for. Learning languages is a skill easily picked up. Learning how to un-muddle code written my others is an art, and people skilled in the art of decoding a mess are much harder to find, let alone identify.

    Transition? One possibility is to find a contractor highly skilled in maintenance programms. If he works out, offer him a partnership.

    As for the attitude that any piece of software can be completely bug-free: that's a holy grail. The ADA Programming Language was invented to try to provide an underpinning to achieving the holy grail -- when was the last time you heard about it seriously? Several research-based languages have been developed that purport to "prove" that they are correct...but watch what happens when an unanticipated corner case hits the code. Many of the advances in languages and compilers focus on finding easy and trivial problems quickly, so a programmer doesn't have to spend time finding and fixing them. (Scripting languages, particularly those that compile "on the fly" such as TCL and most shell scripts, point out the advantage of a proper compilable language; you lose some flexibility, but the overall programmer cost is far lower than tripping over mistakes one at a time, particularly if the programs run are measured in minutes and hours.)

    Your business model will need to change. Count on it.

  • by mcmonkey (96054) on Wednesday May 22, 2013 @09:40AM (#43793241) Homepage

    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.

  • I hear you (Score:4, Interesting)

    by holophrastic (221104) on Wednesday May 22, 2013 @10:24AM (#43793701)

    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.

  • by DarthVain (724186) on Wednesday May 22, 2013 @11:52AM (#43794671)

    I have the same problem.

    However half the time it isn't the contractors fault entirely, sometimes the local IT when setting up the contractors work screw up a script, or implement the DB incorrectly, or any number of things, causing the application to fail pretty fundamentally.

    As someone that has been on the business area testing side of things, it can be vastly frustrating when finding flaws that are so big and so obvious that there is no way the developer even bothered to test (sometimes I wonder how they could even code it without even trying to run it at least once). Or when you point or said flaw, they report that it has been fixed, you go back and test it again, and nothing has changed. Turns out they forgot and just said they did something about it when nothing was actually done.

    Much of this can be solved with contracts and good testing practices. DO NOT having testing as an after thought. Engage the users to exhaustively test. Have them sign off, but do not have the time truncated because the developer was slow or ran into problem. Have set scripted time for testing and build into contract. That way it is spelled out when the developer fails (and so does payment) or when the user client fails to spot bug and they have to take some responsibility also.

    Any many have mentioned, bug free code pretty much doesn't exist for any systems of any size or complexity, or they don't stay that way for very long if they do exist. However you can try to keep it to a reasonable amount of non-core functionality. There can be those bugs that only happen when all the planets align on a prime number Tuesday. Even the most diligent development or user testing can miss it, and only find out much later. Thankfully usually these things are pretty low impact due to the rarity.

    In any case hiring internally is fine, and will allow for more continuous updates to these applications. Find a rare bug a year afterwards, no problem, you have an in house guy that can fix it no problem. The only difficulty is that you better make sure who ever you hire does meticulous documenting, in code comments, and is very organized. An organization can become very dependent on these folks for obvious reasons. When they leave (for whatever reason), you could be quite screwed, and even going back to contractors may be difficult. Languages really don't matter, keep up their training if they have to deal with a lot. Hire someone that has a lot of experience in the primary languages you deal with (or the most immediate need), and let them develop the rest. In your situation, I wouldn't be looking for the "genius level hacker" type but rather the "OCD organized, meticulous, steady" type. Heh, neither are likely fun to be around... :) Someone who is a competent programmer to be sure, and shows some flexibility and range of ability/knowledge/experience but primary skill should be fastidiousness.

Aren't you glad you're not getting all the government you pay for now?

Working...