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. :)
..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
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'
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.
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
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?
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 block and not bricks). The differences may be more subtle than code, but my point is not every wall is built the same way.
When you recognize love in another and realize how precious it is, everything else seems so insignificant.
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.
-73, de n1ywb
www.n1ywb.com
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.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
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.
You're special forces then? That's great! I just love your olympics!
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?
If you are a contractor then almost certainly it should be fixed for free. You are paid to do a job and if it wasn't done right the first time then you need to make it right or expect not to get many more contracts if you leave behind in your wake bugs that either go unfixed, or you charge additional to fix.
I disagree with this blanket statement. If you are a sole contractor who bid on a contract to produce software that does XYZ and it was a fixed price contract, than yes, I would say you need to fix the bugs. But that typically isn't the case for contract workers. They are contracted to fill required services, including development, and code debugging. If they are not satisfied with the level of code produced by the contractor, they have every right to end the contract, but asking for code debugging to be done off the clock is outside the scope of work.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
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.
On the cruelty of really teaching computing science (EWD 1036)
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.
Have a nice time.
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.
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.
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.
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.
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.
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.
I do not fail; I succeed at finding out what does not work.
If you get paid hourly then perhaps. If it is irrefutable that its your fault/bug then you should feel obligated to fix for no extra charge/hours to them. If there is any doubt on the source of the bug (multiple developers) then you should be paid to fix it.
With very few exceptions, having your employees work for no pay is illegal in the US. And, no, fixing a bug that you created is not one of those exceptions.
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
Software analogy to bricks
A brick builder makes a wall. He notices that it's unsteady near the bottom. He tells his manager that the mortar may be bad, and he wants to test it. The manager says they've got a timeline to meet, so keep building. A few bricks fall out, but the manager says they can fix those in phase two...
Then the wall falls down, and the brick builder gets blamed..
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.
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.
It's really quite a simple choice: Life, Death, or Los Angeles.
"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.
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.
US Citizen living abroad? Register to vote!
Where is my ever lasting car? Why am I paying all this money to mechanics over and over again. Only if I had gotten a brick wall to get me to and from work.
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.
BlameBillCosby.com
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.
Everyone and everything has an error rate. Software development is well known not to be a perfect process.
Building a wall (or a better analogy, designing the house the wall will be a part of) is no perfect process either.
I just recently thought about why software is so difficult, compared to physical engineering tasks. A big difference I found (aside from the obvious practicalities, such as lacking proper specification and resources) is lack of tolerance in how software is being built. When you're designing a supporting wall for a house, you calculate how much weight it needs to be able to carry. Then, you multiply that weight by a safety factor, adding tolerance. Similarly, when actually constructing the wall, the bricks don't need to be perfectly aligned, good enough is good enough, the final adjustment can be fixed with bit more or less mortar.
A lot of software is built with low tolerance. Part of it is cutting costs, part of it is just immaturity of the industry. There are already known good practises for increasing tolerance of software development process. Worried about buffer overflows? Use a language that makes them impossible. Data loss? Use a known good DB (and learn to use it) instead of inventing your own storage. Developers writing bad logic? Require proper testing and code reviews. All of the previous requested, but not happening? Bring in a competent project manager.
Then there's the whole other unique issue that software development faces, changing requirements. Construction workers will likely give you the finger, then go drink some beer and laugh about it, if you tell them that the garage they have built half-way actually needs to be a cathedral by the end of the month. In software, that's business as usual.
And then, every once in a while, walls collapse too. Sometimes they find someone who had not done his job properly, sometimes it's just written down as a sum of consequences.
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.
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!
Science & open-source build trust from peer review. Learn systems you can trust.
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.