Slashdot Mirror
Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time?
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?"
developer's B bug only existed because of developer's A bug? Who fixes B's?
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.
You're special forces then? That's great! I just love your olympics!
"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.
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).
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. :)
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?
Atlas stands on the earth and carries the celestial sphere on his shoulders.
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'
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?
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
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.
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.
Is it just my observation, or are there way too many stupid people in the world?
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.
Tell your boss he should be fired. If he's going to make bad analogies, they should at least involve cars.
This is my signature. There are many like it, but this one is mine.
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.
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
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.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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.
Architectural plans are like computer source code with a couple of differences: You only compile once.
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, which currently appears to have ground to a halt amidst massive cost overruns.
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.
Comment removed based on user account deletion
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.