Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time? 716
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?"
what if... (Score:5, Insightful)
developer's B bug only existed because of developer's A bug? Who fixes B's?
Re:what if... (Score:5, Insightful)
The brick builder charges accordingly. Since 90% of programming is debugging and testing, you could concur and demand a 1000% pay rise.
Bad Analogy (Score:5, Insightful)
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.
Your boss knows fuckall about construction (Score:5, Insightful)
"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.
Builder = Business != Individual (Score:5, Insightful)
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).
because it's not work for hire (Score:4, Insightful)
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'
Context (Score:2, Insightful)
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 necessary investigation, due to business constraints, these engineers ensure that the "most common case," of the system works; later, some small side-effect or edge case is discovered, which needs fixing...
* using a 3rd party library that is documented to behave in a specific way, a team of developers build their own product, which effectively plugs into the original 3rd party mechanism. Unfortunately this 3rd party component does not behave the way it was documented to. Now we have to figure out who decided to use this library, who authorized the team of developers to build on it, and the reasoning behind the research that went into this decision (or lack thereof...)
Point is, I've never written software in an Ivory Tower. All of the code I write is constrained by time and cost-effectiveness. Within that framework, which involves forces entirely outside of the developer's control, I write the best code I can. Often, developing software is an exploratory process.. with a goal in mind, and a set of tools to reach that goal, but without a clear set of specific and tried and true techniques.
This is significantly different than building a wall, which is a well documented process and can be repeatable. Your example is inherently fallacious, I would say, because in reality you're performing a set of steps (an algorithm) that has been defined for you - when building a wall. While, when writing software, one is actually defining and testing those steps. Totally different things.
Fucking Stupid (Score:5, Insightful)
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?
Re:Bad Analogy (Score:5, Insightful)
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.
Guarantee (Score:5, Insightful)
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.
Re:what if... (Score:5, Insightful)
** on his own time, that is.
Close, but not quite (Score:5, Insightful)
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.
Bugs are not mistakes. (Score:4, Insightful)
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.
Re:Your boss knows fuckall about construction (Score:4, Insightful)
The closest I've ever seen is threats to take the cost out of my paycheck if I accidentally broke a foundation.
I believe that in the U.S. that would be illegal. In fact, if he was threatening to commit an illegal act against you, you may have the grounds for a lawsuit already.
Re:Guarantee (Score:5, Insightful)
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:Must of been a non-union builder... (Score:4, Insightful)
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.
Re:Guarantee (Score:5, Insightful)
Re:Guarantee (Score:2, Insightful)
Bricks are fairly well-understood, as is mortar, the brick-laying process, and so on. You can fairly easily standardise the process. Nonetheless, basically all branches of construction are known for nickling-and-diming, fraud, shenanigans. Hence the licences and bonds and so on.
Software won't stand up to standardisation so well, for if you could you only needed to modify some existing software package a bit and all is well. "Engineering" software the same way you'd engineer hardware... doesn't work so well. Thing is, nobody knows how to do it instead. So, enter the fads. You could say there's charlatans at large, and no doubt there are. But that's not the whole story.
This isn't to justify the fads, but to illustrate that their existence isn't without reason. We've been building in stone and wood for a lot longer than we've been writing software. If anything, a model like the Germans have for engineering in general --a licensed engineer must sign off on the design, and he's personally liable for provable factory defects-- might work eventually... once we figure out what reasonable standards for software engineering would be.
In the meantime, it's all speculation. And the market reflects that.
On the other hand, it's certainly true that large amounts of people are in no hurry whatsoever to figure out what solid engineering would mean for software. There's much more money to be made in prolonging the problem. You see that everywhere in software, from large ERP software to even operating systems that require an entire security industry to keep somewhat afloat.
Prgramming/compiling vs Engineering/construction (Score:5, Insightful)
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:what if... (Score:5, Insightful)
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.
Re:Guarantee (Score:4, Insightful)
^ 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...
Comment removed (Score:4, Insightful)
Re:what if... (Score:5, Insightful)
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).