Forgot your password?
typodupeerror
Bug Programming

Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time? 716

Posted by Soulskill
from the 10-of-10-employed-developers-say-no dept.
Bizzeh writes "Today my boss came to me with what he thought to be a valid point and analogy. A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher. In most cases, he would have to replace those lower bricks at his own expense and on his own time. Comparatively: A software developer writes a piece of software. When bugs are discovered, the developer is paid to fix them by the employer and on the employer's time. I didn't know how to refute the analogy at the time, but it did make me think: why are bugs in software treated differently in this way?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time?

Comments Filter:
  • what if... (Score:5, Insightful)

    by Chadster (459808) * on Tuesday February 11, 2014 @06:50PM (#46223097)

    developer's B bug only existed because of developer's A bug? Who fixes B's?

    • Re:what if... (Score:5, Insightful)

      by TechyImmigrant (175943) on Tuesday February 11, 2014 @06:51PM (#46223109) Journal

      The brick builder charges accordingly. Since 90% of programming is debugging and testing, you could concur and demand a 1000% pay rise.

      • by Anonymous Coward on Tuesday February 11, 2014 @07:01PM (#46223291)

        The builder was probably commissioned specifically to build the wall, as well.

        The developer was probably commissioned to build something with nebulous requirements like "keeping the Huns out", and this was the only idea his boss could understand to sign off on.

        • Re:what if... (Score:5, Insightful)

          by noh8rz10 (2716597) on Tuesday February 11, 2014 @08:46PM (#46224445)

          If the builder has a fixed price or not to exceed contract, then he has to deliver the goods at that price, and anything else is out of pocket. Same for contract work for software. But also note the difference between a builder company and an independent contractor. If the building company goes over, it still has to pay its employees.

          The submitters analogy sounds like bull poop.

        • by dudpixel (1429789)

          I think the analogy is flawed.

          Software development is probably more like engineering and building a bridge.

          You need to compare with something where not everything is known at the outset.

          I'm sure that bridges sometimes have "bugs" - problems that were not though of in the planning phase. I'm sure no one fixes those for free.

          Is the construction of the bridge equivalent to the software development? or the software release and implementation?

          I think you could perhaps design a model where developer fix their own

          • Real life analogy (Score:5, Interesting)

            by Camael (1048726) on Wednesday February 12, 2014 @12:16AM (#46225719)

            Software development is probably more like engineering and building a bridge. You need to compare with something where not everything is known at the outset.

            Actually, there is a real life building analogy of the type you seek- large scale projects such as the expansion of the Panama Canal [reuters.com], which currently appears to have ground to a halt amidst massive cost overruns [reuters.com].

            So, it is not always true the builder fixes any problems on his own time and costs. In some cases, the client pays (hence the cost overruns) or if there is a dispute, a mess ensues as in the example above.

            • by danheskett (178529) <danheskett AT gmail DOT com> on Wednesday February 12, 2014 @12:30AM (#46225809)

              You are exactly right because at a big enough scale, the builder simply can't absorb the losses. So whatever you extract for a promise from the builder, it doesn't matter, because their is no more money.

              Even when "bonded", the amount of the bond can be insufficent. Then what?

              That's why essentially every big government job has overruns and the people causing the overruns "pay for it", but not really. The contractor's only line of business is government work. Paying a fine or the cost of the overrun means that the next contract has that much more built in to pay the risk premium.

              In the end, this type of scheme is just that a scheme, to shift risk from the party that stands to ultimately profit to a bit-player. It can only go on for so long.

        • Re:what if... (Score:5, Insightful)

          by gl4ss (559668) on Wednesday February 12, 2014 @02:30AM (#46226265) Homepage Journal

          contracted vs. employed.

          if you're employed to do the job, then sure as fuck you don't fix them on your own time.

          if you were contracted, then it'll depend on the contract. governments seem to be fond of making contracts where the government pays for the fixing though...

          if the guy has a boss - then the boss should understand that he is asking his employees to work overtime for free.. if he wants that, then maybe he should start just contracting people to deliver a product(versus delivering work hours).

        • Yeah. This guy's boss is an ass hat. The analogy involves a contractor. If that contractor wall-builder has employees, no, they don't actually work for free. Meanwhile, in addition to the labor rates the contractor charges, they'll have overhead for business operation, risk, and profit margin. So if this guy's ass hat boss is expecting that, then he should expect to pay a lot more for the work. Idiot.

      • Guarantee (Score:5, Insightful)

        by Roger W Moore (538166) on Tuesday February 11, 2014 @07:08PM (#46223401) Journal

        The brick builder charges accordingly. Since 90% of programming is debugging and testing, you could concur and demand a 1000% pay rise.

        Actually the builder offers a guarantee that the wall will be built to industry standards. Since there are lots of people who can build walls without serious flaws the industry standard is that the wall has no serious flaws and the builder will usually offer a guarantee to that effect - or at least the contract will not contain any exceptions for serious flaws. Indeed nobody would hire a builder who's contract stated that they offered no guarantee.

        In software it is not possible in practice for someone to write a non-trivial program without any bugs. Hence it is not common practice to expect completely bug-free code and contracts usually have stipulations to that effect - just look at all the exceptions and explicit non-guarantees in your typical EULA. Essentially the cost of offering a guarantee like the builder's would be so astronomical that nobody would hire you.

        • by msauve (701917) on Tuesday February 11, 2014 @07:16PM (#46223505)
          "Mother did it need to be so high?" - Roger Waters.
        • In software it is not possible in practice for someone to write a non-trivial program without any bugs.

          I will do it for you. It will cost you an astronomical amount. You won't be able to afford it, but if you can pay, I will do it.

          If you are wondering how it can be done, it will be an extremely well defined specification, a formal verification (partially automated), combined with a penalty-per-bug that is cheap enough for me to handle (this is similar to the SLA for many companies that guarantee 99.999% uptime).

        • Re:Guarantee (Score:5, Insightful)

          by NoKaOi (1415755) on Tuesday February 11, 2014 @07:28PM (#46223645)

          Actually the builder offers a guarantee that the wall will be built to industry standards.

          Actually, if you want to follow the analogy, the employee is not analogous to the builder. The employee is analogous to the builder's employee, while the builder is analogous to the company, and the homeowner is analogous to the company's customer. The builder would be paying his employee by the hour. If the employee messed up, whether it was a reasonable mistake or even if he was negligent, when the employee fixes his mistake he'd still be on the clock, getting paid by the builder. Of course, the builder could fire the employee and hire another employee to fix it, but he can't make the first employee fix it off the clock.

          • Re:Guarantee (Score:5, Insightful)

            by jythie (914043) on Tuesday February 11, 2014 @07:52PM (#46223973)
            The builder (or builder`s company) is also generally licensed and bonded. Most modern software shops have pretty much given up on software engineering and jump randomly from fad practice to fad practice with almost no maturity or consistency. Something as rigorous as following standards, licensing, carrying insurance... their heads would explode.
          • How about a car analogy.

            I bring my card into the shop. Mechanic says "needs X", installs new parts, gets paid.

            I drive back in. Same problem. Mechanic looks again. Says "needs Y". Installs new parts, gets paid.

            No refunds or free rework there, even though it's obvious that the initial diagnosis was faulty. And, alas, sometimes the second diagnosis as well.

          • Re:Guarantee (Score:5, Interesting)

            by smartr (1035324) on Tuesday February 11, 2014 @08:23PM (#46224229)
            Nonsense, the builder's employee is analogous to the computer itself. Programmers are far above the low level work of brick laying. Programmers are more like experimental architects. Less experienced or simply more optimistic programmers will make more mistakes because they're constantly learning. One might further say that a programmer, who by trade is exercising the trade of "computer science", is in fact closer in position to that of a scientist. If scientists only got paid when their hypothesis was correct, no matter how many experiments were run, not much science would be getting done. If an employer does not understand this risk, they probably are not prepared to be doing business in the industry and might also want to double check their employee tax obligations.
          • by Elfich47 (703900) on Tuesday February 11, 2014 @08:29PM (#46224289)
            Very simple difference:

            In construction the design is cheap (5-10% of the building cost) and the compiling is expensive. In construction you only get to compile once. In addition anything that leaves an engineers or architect's office that has been stamped and signed is certified to provide a working structure, building or system; assuming the builder follows the plans correctly. Everything must be installed in the correct order and location. Deviations from the plan (we are assuming the plans and specs are good) involves and expensive reworking, redesign and law suits.

            In programming, the expense is in the design of the system, compiling is cheap. In computer programming you compile as often as you need. One can test run sections of the code as needed to see what works and how it interacts.

            The labor requirements are flipped between the two industries. Trying to compare the two can lead to some poor analogies quickly.
          • Re:Guarantee (Score:4, Insightful)

            by jtara (133429) on Tuesday February 11, 2014 @09:20PM (#46224697)

            ^ A much more appropriate analogy, that almost fits.

            Add to this the fact that the builder (employer) told the bricklayer (employee) to leave out every other brick on the bottom row in order to save time and expense, and you'd have an analogy that is spot-on...

          • by raymorris (2726007) on Wednesday February 12, 2014 @12:32AM (#46225819)

            This is the difference. Employment where the payer takes the risk and reaps the rewards, vs contracting, where the seller has the risks and rewards.

            If you contract a brick company to build a wall (at $150 / hour), they will in turn employ brick layers at $15 / hour. The $135 difference is that the contractor is paid to get the wall built, even if it takes three to.es as long as expected. The bricklayer is paid to show up 8-5 and lay bricks. For $15 / hour, he is responsible for showing up and doing what the boss says, NOT for the results.

            I do both in programming. Customers call and get a bid on a project. If I have to work until 2AM to get the project done, I work until 2AM. I bid those projects based on $125 / hour - however many hours I think it'll take, I multiply that by $125 to set the price. I also work for a government agency, as an employee. They pay $50 / hour, and I leave work at 5:00, whether the job is done or not. If they want me to spend my off hours working on it, they can a) pay contract rates and b) not complain when I go home at noon because the job is done.

        • Capital vs labour (Score:4, Interesting)

          by TapeCutter (624760) on Tuesday February 11, 2014 @08:02PM (#46224067) Journal
          The whole anaolgy fails miserably. The "builder" is a small bussiness, the coder is an employee. The builder's employee who fucked up the wall does not pay for it out of his own money/time, for the same reason his wages don't double when company profit does. An employee is not a one man company, nor should it be, any employer who tells you otherwise is trying to screw you.
        • The day software is repetitive as the wall builder is the day we can offer such a guarantee.

          Lucky for us, the compiler is pretty darn good and repetitive that we could do it for such a task.

          I will guarantee that the same code compiled over and over again will perform the same.

          The answer to the boss is really that the compiler is the builder.
          I am not a manufacturing worker. I am the mechanical engineer.
          I am not a construction worker. I am a civil engineer.
          I am not a compiler. I am a designer.

          How often do des

        • by khasim (1285)

          Actually the builder offers a guarantee that the wall will be built to industry standards.

          And to the exact specifications that were provided to him, in writing, at the time he bid for the job.

          Try getting a builder to build the wall "just a bit higher" or "just a bit wider" or "just put a window in that patch you've finished already". Not going to happen.

          Which is why programming is not the same as construction.

          Indeed nobody would hire a builder who's contract stated that they offered no guarantee.

          And, likewi

      • by Darinbob (1142669)

        Brick builders charge according to the job, not how long it takes (though workers themselves may be on the hour, it's the contractor who eats the price of redoing the work).

        Developers don't typically get paid per job, except maybe some contractors. A salaried developer at a corporation however doesn't have to work on their own time to make up for defects, as fixing defects is a primary function of the position.

        5% of my coding time is spent on new code, 95% if coding is spent fixing defects. That's been so

    • by fl!ptop (902193)

      developer's B bug only existed because of developer's A bug? Who fixes B's?

      This is what I was thinking - what if the builder's bricks were falling out because the mortar he used was bad?

      • Re:what if... (Score:5, Interesting)

        by DaveAtFraud (460127) on Tuesday February 11, 2014 @06:56PM (#46223189) Homepage Journal

        or the design of the foundation is incorrect, or the client wanted a wooden wall instead of brick, or the brick manufacturer changed how the bricks are made becuase of a change in the brick standard, or the bricks had to be changed because they were found to be vulnerable to attacks by clay termites, or ....

        Bugs are rarely just he result of a programmer screwing up.

        Cheers,
        Dave

        • Bugs are rarely just he result of a programmer screwing up.

          That's rather kind. Bugs happen all the time just because programmers screwed up.

          The difficulty with the software industry is that we have not yet developed good objective criteria for saying which bugs are really down to a specific programmer's error as the root cause and which could instead be attributed significantly or entirely to other causes. What's more, we have even less ability to set criteria that are still useful if you're a lawyer or manager or client rather than a technical expert who understan

          • by Belial6 (794905)
            An even bigger problem is that with software, we don't get to just say "Close Enough". If you look at any building, bridge, wall, whatever, you will find huge numbers of defects. If the bridge doesn't fall down we say "Close Enough". With industries like medicine, standards are even looser.

            Software development is just about the only industry where perfection is expected.
          • Bugs are rarely just he result of a programmer screwing up.

            That's rather kind. Bugs happen all the time just because programmers screwed up.

            The difficulty with the software industry is that we have not yet developed good objective criteria for saying which bugs are really down to a specific programmer's error as the root cause and which could instead be attributed significantly or entirely to other causes. What's more, we have even less ability to set criteria that are still useful if you're a lawyer or manager or client rather than a technical expert who understands how things actually work.

            Having spent about one-third of my career in software QA, it's really not that hard to tell which bugs are programmer screw-ups and which ones have a deeper cause. Although there is that grey area where the programmer didn't understand the underlying system or some interfacing system because the documentaion sucked.

            Cheers,
            Dave

  • Bad Analogy (Score:5, Insightful)

    by rjstanford (69735) on Tuesday February 11, 2014 @06:53PM (#46223131) Homepage Journal

    If a bricklayer, working for a wall-building company did this, then he'd be paid his normal wage to fix the wall (or fired if it was an egregious enough problem).

    The wall-building company itself may indeed fix the wall gratis, but a certain amount of re-work is already baked into their bids. That's one of many, many reasons why companies bill out workers at 2X-3X the amount that they pay them (see also taxes, offices, holidays, paid downtime, &c). Its a cost of doing business for the company, not the employee.

    If you're a 1099 contractor then I'd say that if you were working hourly it'd be the same situation as if you were an employee; if you'd bid the project as a project then I'd expect you to deliver it properly functioning, but again I'd also expect that your bid would have accounted for some possible rework.

    • by rjstanford (69735)

      The word "builder" in the summary is more than a little confusing, since it may refer to anything from a large company responsible for developing raw land into finished houses to a single person responsible for putting bricks on a foundation. Colloquially the latter may be more common, and indeed I believe that the summary is written in that way, however in the industry I believe the former would be the assumed definition (its short for "homebuilder").

    • Re:Bad Analogy (Score:5, Insightful)

      by Anonymous Coward on Tuesday February 11, 2014 @07:07PM (#46223365)

      This is Insightful, not "Interesting". In most sane nations, there are things called laws that govern how employers must treat employees. In almost all cases,

        1. mistakes by employees are owned by the employer
        2. the employer must pay employees for their time, irrespective if they are correcting their mistakes, others, or whatever.

      If the employer does not like the work of an employee, they can fire them. But they cannot demand employees work for free. Money flow is always one way, even if employees were negligent.

      The sad thing is, there are plenty of shitty employers that take advantage of complicit or mostly ignorant employees. The bottom line, if there is an employment contract and there is employment law that can trump contracts. Employees would be well advised to understand both.

      So for the original question, if an employer is telling you to "fix problems for free",

        1. start looking for a new job
        2. document all time you've spent fixing stuff on your own time (or better, refuse to work for free)
        3. after you get new job, contact a lawyer regarding local labour laws.

  • by Anonymous Coward on Tuesday February 11, 2014 @06:54PM (#46223137)

    "In most cases, he would have to replace those lower bricks at his own expense and on his own time."

    LOLWHAT. What construction company says "turns out there was a flaw in our design, or maybe you made a mistake. Come back after hours and fix it on your own time." I'm pretty sure that has happened 0 times in legitimate construction. It would be chalked up to a mistake and would be rectified by the construction crew, not one dude with a bucket of bricks and some concrete at 8pm the following night.

  • ...if it was a union job, the employer would be paying twice.

    • by rmdingler (1955220) on Tuesday February 11, 2014 @07:35PM (#46223741)
      While influential unions are infamous to a near mythical degree for protecting mediocre tradesmen, their real strength lies in the ability to bottleneck the number of skilled tradesmen for a particular task in a given location.

      There were a couple of generations after WWII where one could argue they became unnecessary, even tainted by organized crime in some circumstances. Current trends toward employment in jobs with subsistence wages, like any job in retail, make a case for the resurrection of worker's unions. These days, I am afraid the manufacturers of the World have virtually collectively decided the Western standard of living has become unacceptable to them.

      I find it funny (funny strange not funny ha-ha) elite earning athletes have collective bargaining agreements, and people who work at Walmart qualify for government benefits.

  • by shri (17709) <shriramc@gmail . c om> on Tuesday February 11, 2014 @06:55PM (#46223149) Homepage

    The analogy is incorrect. The builder is often the business owner and it is the business that is paying to remedy the defects. If the mechanic at a car dealer got something wrong, it would be the car dealership's problem, not the employee's problem (he could get fired .. but he would not have to pay for the replacement - assuming this was a sanely run business).

    Costs of bugs / fixes etc are built into the product development cycle.

    Would be another story if you came into office drunk and added a whole lot of code that then needed to get fixed. i.e. You were personally negligent and should be held liable for your actions (in my opinion).

    • by nospam007 (722110) *

      "The builder is often the business owner and it is the business that is paying to remedy the defects. "

      I don't know how it is in the US, but where I live, builders have to have an insurance that guarantees free repair for faulty work for 10 years, even if the company goes bust.

  • Correct me if I'm wrong, but wall-building happens pretty much the same way every time. There are building codes and whatnot. The builder has built the exact same wall many times before.

    Code is usually the opposite. It is more like building a bridge or a skyscraper. They're generally all different and involve architects. I'm pretty sure if there is a budget over-run when building a skyscraper the common practice is for the client to pay. Actually in some cases it is the contractor who pays, but the key poin

    • by fl!ptop (902193)

      Correct me if I'm wrong, but wall-building happens pretty much the same way every time. There are building codes and whatnot. The builder has built the exact same wall many times before.

      Sort of. If the wall is built in a cold weather climate, the mortar mix is different than that of a warmer climate. Some walls are built to hold a load from the top, others may be built to hold back a load from the side. In the latter case, you'd probably want to use rebar and concrete to fill the voids (assuming it's blo

    • by Overzeetop (214511) on Tuesday February 11, 2014 @07:13PM (#46223479) Journal

      You mean you never reuse the same code, or use a pattern of progress to build code? It's completely chaotic? No, of course not.

      Interestingly, when you build a bridge of a skyscraper, and your part fails (for some reason - nail pops in drywall, paint doesn't adhere tot he steel, the road surface is too rough) you redo the work for free. Now, that's the corporate "you" not the personal you. The person making the bid covers it
      (subcontractor, contractor, consultant, whatever), not the employee generally. And, if the architect or engineer designs it wrong and the plans don't meet code - they generally are required to redesign it for free. There are even some contracts which are price dependent - if the estimated cost of the project exceeds the budget the architect has to redesign it for free (analogy: you write code and it takes too many compute cycles/doesn't run of reference hardware).

      As for payment, cost overruns which are the result of poor or incomplete workmanship (bugs) are nearly always born by the person doing the shoddy work, never the client (unless the client decides they want to pay for some reason, or are too removed from the work to realize they've been double charged).

      Although I've known contractors to make employees fix screw ups on their own time, it's generally the company that bears the burden of the repair costs - so the OP should have said that, had he been contracted for a fixed fee to complete the job, yes - up to a limited warranty period; as an employee his contract is to perform services at an hourly (or weekly or yearly) rate. The corporation pays the employee a far lower wage than the equivalent hourly rate they receive for the product, because they take those risks.

  • by RichMan (8097) on Tuesday February 11, 2014 @06:55PM (#46223155)

    Bugs are escapes from the QA process. The QA people can fix them on their own time as the fault is in the QA process not the developer. :)

  • If he is the amount he is charging doesn't change, he just ends up earning less per hour. If the builder is an hourly employee he will be getting paid hourly but the company he works for will make less money or even lose money. You are an employee, you receive an hourly wage or a salary for your efforts. If the company finds your efforts lacking they can fire you.

  • by MpVpRb (1423381) on Tuesday February 11, 2014 @06:56PM (#46223173)

    ..of software development, and even the best of us aren't very good at it

    If there was a foolproof procedure to guarantee bug-free code, and only the lazy or incompetent produced bugs, things would be different

    Unfortunately today, a talented, competent developer, using best practices, always produces bugs

  • by codegen (103601) on Tuesday February 11, 2014 @06:56PM (#46223177) Journal
    What if the boss told him that he had to use these cheap thin bricks. He told his boss the bricks wouldn't work but the boss insisted that he use the inferior bricks. What then?
  • by hguorbray (967940) on Tuesday February 11, 2014 @06:57PM (#46223193)
    if you pay someone by the hour (or month) to write a document and there are typos, mispellings or factual errors you pay either the writer or an editor to take more time to make corrections.

    An exception would be if they are being paid solely upon the delivery of piecework(work for hire), in which case they would still not be liable to to fix if it were signed off (accepted) by the purchaser as having met the agreed upon criteria...

    The building analogy does not hold because writing and coding are(hopefully) iterative processes and some times you have to rip up or shift the foundations

    -I'm just sayin'
  • Aren't bugs impossible to avoid in programming, especially in complex projects? There's no such thing as a perfect programmer or perfect code; things can always be fixed, optimized, debugged, and improved. The brick wall analogy simply doesn't apply.

    • by rjstanford (69735)

      I've yet to see a building project as complicated as a garden shed that's perfect either. That's why everything is measured to "within tolerance," where the tolerance is either implicitly (through industry norms) or explicitly (through contract) agreed upon by both parties.

    • Aren't bugs impossible to avoid in programming, especially in complex projects? There's no such thing as a perfect programmer or perfect code; things can always be fixed, optimized, debugged, and improved. The brick wall analogy simply doesn't apply.

      It's worse than that. Writing a program is like writing a contract with the Devil. You'll get exactly what you asked for, not exactly what you wanted.

      Very few people have mastered the incredibly subtle art of knowing what to ask for in that much detail. And it really is true that one person's bug may be an incredibly useful feature to another person.

  • Context (Score:2, Insightful)

    by Anonymous Coward

    Well, this case requires a lot of context. The phrase, "bugs" in software can be very ambiguous and can have many meanings. At the end of the day, it means the software isn't working the way someone thinks it should. However, the route that was taken to this moment can be widely varied.

    Some short examples:

    * working under deadlines, developers complete products they know are not thoroughly tested and may have side-effects and bugs that they are not aware of. Being unable to take the time to do the necess

  • If your boss makes foolish comments that show a fundamental lack of understand of the complexity of real world problems should he forced to return to elementary school on his own time?

    That is a hard question. Where would he find a suitable school?

  • Guess you should be looking for a new job. No point in sticking around to work for such a terrible boss.
  • Granting the base premise, like a lot of other situations, it depends. Is this a syntax bug, or a semantic bug? A syntax bug should be caught in testing, unit or validation. A developer should be conscientious enough to avoid those. Semantic bugs are going to be more difficult. Did management or the customer change the spec after the code foundation was laid? If so, that can't be held against the developer.
  • To use the building analog, did they use an architect to design the building? Did they have engineers inspect the drawings to ensure that it won't fall down? Did they inspect the quality of their materials to ensure that could support their specifications? Or he just ask you to keep piling bricks and was shocked that bricks were falling out at the bottom?

    Is code just a bunch of bricks? Bricks are pretty simple, they don't have to do anything but exist. Code is logic, and given some specifications you wri

  • Fucking Stupid (Score:5, Insightful)

    by cosm (1072588) <thecosm3@gmail . c om> on Tuesday February 11, 2014 @06:59PM (#46223255)
    Either your manager is an idiot or you are misinterpreting his analogy. The business entity that causes the defects pays for the defects if they are within the terms of the contract. The builder is a business entity (S Corp or LLC, etc), just as much as XYZ Co. selling Desktop Bullshit 5. The employees of the business are generally shielded from mistakes the business makes. This is not unique to software development. A flaw in a Boeing 777 does not come out of the paychecks of the engineers that built it. They are either fired/retrained/retained for the re-engineering project, management is fired (or today promoted), or contracts are dropped/re-worked, and the work is redone on company/business entity dime. The same company that built it will be the same company that pays for fixes.

    If I paint 'ole Ms. Gladys fence and miss a post, going back and "doing it on my own time" is trivial in terms of time-cost. But if my corporation writes an enterprise HR system for managing her egregious cat collection, it is my corporation that will fund the bug fixes for an erroneous bug that miscounts turds per feline. That cost of doing business will come out of my corporation's margin, not my employees paychecks.

    In enterprise environments there are SLAs that cover this sort of thing. Why is this drivel on the front page? Somebody's first time discovering they can email scripts for their Joe's Home Programming business or is the editor-community here (he said sighing...) that detached from how enterprise development works?
  • Assuming you could implement this policy, people would spend so much time trying to ensure that it works properly that they would be take far too long to complete it.

    If someone is releasing buggy code, they will have a poor performance review. This should be enough to ensure that code is of high quality. If this isn't a good enough motivator, then simply emphasize more in the performance review, and if necessary, indicate the possibility of an early performance review.

  • If you are an employee, you don't have to fix bugs or bad walls on your own time. If you're are a subcontractor that may be expected by some. At my company when a contracting company (including a 1099 or individual corp) is on T&M and screws up - terrible design, incompetent programming, etc., we still pay them until we decide to end the relationship. The alternative is fixed price contracting or a form of "piece work", but that puts a big burden on our own incompetent and clueless managers. They'd r
  • by The MAZZTer (911996) <<megazzt> <at> <gmail.com>> on Tuesday February 11, 2014 @07:02PM (#46223309) Homepage
    Make an analogy about how politicians don't fix any of their problems and get paid to make more, and ask why you can't do that?
  • A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher. In most cases, he would have to replace those lower bricks at his own expense and on his own time.

    If the builder is an independent contractor it will depend on the bid. If it is time and material he won't, but if the contract is for the job he will. If the builder is an employee he is never responsible: He either learns not to do that or he should be fired.

    It is the same for software

  • by pipedwho (1174327) on Tuesday February 11, 2014 @07:04PM (#46223329)

    The problem isn't that the developer has created a bug that he has to fix. It's that the cyclic process of development / debugging / testing are not being correctly accounted. Or more than likely, the second two phases are being ignored as part of the accounting.

    If the developer were to be responsible for his bugs, then his time must have already included the debugging and testing phases. By the time the process is complete, there are a number of people in the loop who are 'responsible' for the remaining bug. If the process has not been correctly established, then the problem isn't with the developer, it is with the management. Therefore, the management should be paying out of their pocket for the developer to fix the bug.

    There is no inherent reason why an employee that is part of a much larger process is somehow responsible for the entire process. Even the bricky isn't responsible that someone else gave him a bad batch of cement. The company should have planned for this and padded their estimate with appropriate margin to mitigate expected (and to some degree unexpected) risk.

    Too many 'managers' do not understand that debugging and testing take more resources than that required to write the initial lines of code.

  • by n1ywb (555767) on Tuesday February 11, 2014 @07:05PM (#46223349) Homepage Journal
    1. Most software projects are reasearch and development; buiding something new that's never been built before; hence there's a lot of risk. It's not like a wall that people have been building the same kind of wall for thousands of years. Risk costs money. The only question is who's going to pay for it. Hint: the boss, unless you're stupid, or you have some sort of equity you want to protect.
    2. If you're an employee, the boss has two choices; pay you to fix it, or fire you. Construction and programming are the same in this regard. Maybe he can take it out of your salary, I dunno, might depend on emplyment terms or state law. But typically he cannot compel you to work for free; that's called slavery.
    3. If you're on contract, you're only obligated to fix your mistakes to the extent that the warranty clause demands it. No warranty clause no fixie. The boss may be able to terminate the contract or just not contract with you again, his choice. Your choice if you want his buisness bad enough to fix it for free. Again, construction and programming are the same in this regard. If you do have a warranty clause you will typically bake your own cost of fixing your own bugs into your bid and or hourly rate so it's still not really free for the Boss, your bugs still cost him money.
    • by n1ywb (555767)
      Of course if you're OT exempt salaried then you get to work as many hours as your boss says, or quit, or be fired. But market rules still apply in the big picture.
  • by bobbied (2522392) on Tuesday February 11, 2014 @07:06PM (#46223353)

    If you where working in any other industry, you'd get paid to do rework. Programming *should* be the same.

    Problem is that it sometimes doesn't work out that way. Programmers are usually "Salary Exempt" in the USA, which means that if your bug breaks something and schedule is suffering, guess what? You fix it but you don't get paid more to do that. Sometimes that means burning the midnight oil during the nights and weekends. The same thing happens if you fall behind schedule. More hours, same pay.

    This is the same question as "Should programmers get paid for over time?" Should employers be allowed to expect their salary workers to put in more than the standard work week? And for me, the answer is "it depends". If an employer is being flexible with me and my hours, I'm going to be flexible too. If you demand I'm in the office from 8 to 5 without fail, or suffer the consequences, don't expect me to stay outside those hours. If you are flexible about arrival and departure times, I don't mind working a extra, especially when you reach the critical phases of some project. But this should be the rare exception, and not the rule. When it becomes the rule, I'm going to start looking for other work if they do not cough up some kind of reward for extra hours.

    You can do what you want though.

  • A wider question is why is not there any liability for programming errors? All end-user licenses (both free and otherwise) explicitly renounce any such — and we accept it. Maybe, we should not [acm.org]...
  • Unless he/she can be educated. Presumably this is coming from a non-progammer type. You'd think this person might question why none of the world"s greatest software companies have adopted this practice for their employees (at least I hope they haven't).

  • If the boss demands that the builder builds the Great Wall of China in a week, he has nobody but himself to blame when it falls over.
  • A wall is precisely defined by the one who gives the builder the order.

    If this analogy would work, then your boss would have to hand you the EXACT specifications, to the very minute detail, before you start implementing anything. Something tells me that is not what your boss does.

    So, as your average software developer, your task isn't to implement a system that is 100% specced out. Your job is also to spec that system, based on ambiguous and incomplete specifications. And to make matters worse, the specs wi

  • Under the constraints of the analogy sure. If a developer ignored an obvious defect, bricks falling out the bottom, early in the process then sure the developer should repair them immediately. However, there is no such thing as a perfect wall or perfect house. You inspect the wall, or house before you sign for it, and if you agreed that it meet your expectations then you pay for it, or whatever the contract required. Some houses come with insurance that in case a defect is discovered within a grace period
  • by Xeno man (1614779) on Tuesday February 11, 2014 @07:15PM (#46223501)
    When a builder builds a wall, all the factors are known for what the wall needs to endure. Weight it must support, elements and temperature it will be exposed to. The builder should know how to mix mortar and the steps involved with building a wall as he has probably done it many time before. If bricks are falling out, he has made a mistake, too much water in the mortar, too cold to work, something a more experienced worker would not have done and known about.

    When a developer writes software, all factors are not known. Each piece of software is unique and designed to meed the clients needs. When bugs are discovered, they are factors that were never originally considered possible. People with names longer than the character field, leap seconds, changing daylight savings hours, operating system changes, network growth, hardware upgrades. Regardless of the developers experience, no one will be able to account for these unknowns and how new code for new features will interact with older code. Bugs usually are not from screw ups but from changing factors beyond anyone's control.
  • by RR (64484) on Tuesday February 11, 2014 @07:17PM (#46223521)

    On the cruelty of really teaching computing science (EWD 1036) [utexas.edu]

    Computer code is not bricks. It's completely different. So, your analogy based on bricks is not valid.

    There was a better analogy I read somewhere. Programming is like building only if you're in some insane universe where you make one little slip-up and the entire structure turns into a black hole. But I don't remember who wrote that.

  • by TsuruchiBrian (2731979) on Tuesday February 11, 2014 @07:18PM (#46223525)

    The problem is that when you entered into a contract (either with a customer or an employer), chances are this kind of mechanism wasn't stipulated. If ti were, then they would have presumably had to pay you a much higher salary to get you to agree.

    Any reasonably complex software is a product that is with almost certainty going to contain bugs. If you are willing to be on the hook to fix every future bug discovered for free, you'd better charge enough up front to make this deal worth it.

  • by king neckbeard (1801738) on Tuesday February 11, 2014 @07:18PM (#46223533)
    Tell your boss he should be fired. If he's going to make bad analogies, they should at least involve cars.
  • by Solandri (704621) on Tuesday February 11, 2014 @07:19PM (#46223553)
    And only if the software fails to deliver on the specifications laid out in the contract. If it crashes when they try to use the software on a different dataset than the contract specified, that's not your problem. If the software doesn't perform as per the contract, then yeah the onus is on you (the contractor) to fix it. If you've already been paid for the job and used up that money, then yeah you need to fix it on your dime.

    If you're an employee though, then there is no distinction between your work and the company's work. They are one and the same. If you deliver buggy code, the company delivered buggy code, and the company has to fix it (whether it be by telling you to fix it, or reassigning/firing you and getting someone else to fix it). Same reason the company is liable if an employee screws up and causes a fire which burns down an apartment complex.

    Assuming you're an employee (if you're a contractor, technically you don't have a boss at that company - having a supervisor who can tell you what and how to do your job makes you an employee per IRS definitions), you can turn the argument on its head against the boss. Since he hired you and was responsible for managing you to produce the required bug-free code, if you fail to deliver it and refuse to fix it on your own time, then per his reasoning it becomes his responsibility to find someone who will fix it, and he has to do it on his own time and pay for the new hire out of his own pocket.
  • by Arancaytar (966377) <arancaytar.ilyaran@gmail.com> on Tuesday February 11, 2014 @07:19PM (#46223557) Homepage

    Software bugs are not caused by developer incompetence. They are a natural result of iterative development, where you write code, test and adjust it until it is done.

    The brick wall analogy is completely nonsensical. When you are done building a brick wall, you can tell that it is done. There are no edge cases, requirement changes or memory leaks that can unexpectedly make it fall over.

    If you are guaranteeing the perfect correctness of your software's first version with your own time, then you're not really a salaried employee. You're selling finished software and an unlimited support contract - and compared to those standards, you're undercharging pretty heavily.

  • by dcollins117 (1267462) on Tuesday February 11, 2014 @07:21PM (#46223573)
    Yeah sure I'll fix it on my own time. And by "my own time" I mean if and when i feel like it. Otherwise, I'm getting paid.
  • by msobkow (48369) on Tuesday February 11, 2014 @07:26PM (#46223619) Homepage Journal

    Software has bugs. Get over it.

    This is just another manager trying to get free work out of the staff.

    To hell with leeches like him.

  • by mendax (114116) on Tuesday February 11, 2014 @07:49PM (#46223919)

    If it were yes, the paid Dice minions who are working on the Slashdot Beta will be working for free for a long time.

    Returning to all seriousness now, software development is by its very nature an imperfect activity and will, as a result, result in buggy code, especially if it is rushed and not well designed. When I was in school a long time ago toward the end of the mainframe age, I was told by one of my professors that IBM once studied the problem of the creation and fixing of bugs. Their results was that for every bug fixed, two more bugs are created. If this were true (and I believe it is), we coders would always be working for free. I don't like that idea.

    • Also the building companies know how much time is required to build a wall and every step of the way is time budgeted. If you wait too long to put the next brick on the mortal, it would be too dry and won't hold the brick. If you don't mix the mortar components long enough, then it might not hold up properly. Also the end product is very well known in advance (eg size, mortar color, brick colar, rows of bricks, etc). The customer agrees to the wall on paper before the work starts and can't go back saying "t

  • by tsqr (808554) on Tuesday February 11, 2014 @07:50PM (#46223931)

    "Working for free" is a rather nebulous concept for most salaried professionals, since most of us tend to put in a bit of unpaid overtime on a fairly regular basis. If your boss is suggesting with a straight face that you should decline being compensated until your bugs have been fixed, he's probably an idiot, and may actually be dangerously sociopathic. You might want to ask him about the last time one of his bone-headed decisions resulted in his turning down his paycheck.

  • by kevin lyda (4803) on Tuesday February 11, 2014 @07:54PM (#46223979) Homepage

    It's a great question.

    The answer to the question is to update your CV, go apply for some jobs and take one of them. Because right now you work for an asshole.

  • by turp182 (1020263) on Tuesday February 11, 2014 @08:01PM (#46224047) Journal

    Didn't read the article or any comments, this is Slashdot afterall... Consider a couple of situations.

    Bugs Due to Lack of Knowledge or Incompetence

    This should lead to the person in question leaving the company. I've seen it at the C level and have successfully recommended it at the developer levels (so and so isn't working out, then they are out).

    Accidental Bugs

    I may write a bug everyday. Seems like I do after UX/QA/UAT testing. Fixing them is part of the job, not my personal life.

    Call a bug a mistake then executives (and managers) make mistakes all of the time. At the C-level, strategies are altered and hopefully the new course is better. No guarantee (see Incompetence above). We all deal with our own mistakes (and it is up to the individual where to spend extra time and effort).

    The same mistake (or an unknown, very common in my experience) by regular employees (BA, IA, QA, UAT, etc.) is essentially the same. Missing something, or letting a bad situation through, is similar in spirit to a bug. People should accepts their mistakes, correct them, and continue on. If not, see Incompetence above.

    Reality

    Give me a complete set of perfect requirements (UI included) and I can deliver using the best architecture approaches possible, every time.

    If not, see the Incompetence above.

    But perfect documentation/design isn't possible in reality, so bugs (coded or designed) will occur.

    Fixing them is just part of the job until Incompetence is identified, see the Incompetence above.

  • by snadrus (930168) on Tuesday February 11, 2014 @08:37PM (#46224359) Homepage Journal

    My latest bugs are along the lines of:
    Me: Here's the most rough proof-of-concept, prototype implementation.
    Mgr: Ship it
    Me: It only does some of what's needed, even then most common considerations aren't done.
    Mgr: Ship it. Log that other stuff as bugs. We will close most of them until someone complains.

    So according to your thoughts, employers only pay for the prototype & I'm responsible for the full implementation? No go!

"Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt

Working...