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.
Re:what if... (Score:5, Funny)
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)
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: (Score:3)
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)
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.
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).
Re: (Score:3)
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)
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:Guarantee (Score:5, Funny)
Re: (Score:3)
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: (Score:3)
And you will deliver a product with bugs, because -- no matter what you think -- you're not God, just someone with a breathtakingly deluded sense of their own inerrance.
Of course he will deliver a product without bugs. It will just take very, very long time.
Re: (Score:3)
Formal proof of design correctness doesn't preclude technical flukes.
On the contrary, do you know the technological process to produce CPUs with varied speed and varied number of cores in the same family?
Make a single design. Manufacture exactly the same wafers. Test the built CPUs, stress-test their capacity to perform at varied speeds.
Surprise: the results vary wildly from chip to chip, made with exactly the same design, machine, process.
These made with less contaminants will perform better and be labelle
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:Guarantee (Score:5, Insightful)
Re: (Score:3)
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:4, Informative)
Your using the wrong mechanic. I've had free labour, and even free parts from my regular mechanic after he's realised he misdiagnosed a problem originally.
Re:Guarantee (Score:5, Funny)
> An old truck of mine died one day on the highway, leaving a toll booth.
Please send my condolences to the toll booth. The loss of a parent can be devastating.
Re:Guarantee (Score:5, Interesting)
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: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...
THIS! Employee vs. contractor. $150 / or $15 (Score:4, Informative)
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)
Re: (Score:3)
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
Re: (Score:3)
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.
And, likewi
Re:Guarantee (Score:4, Interesting)
"Part of the problem is that the programming profession hasn't had its professional renaissance like the medical profession had in the twentieth century."
No, it isn't.
The current state-of-the-art is such that programming is still as much an art as it is a science. If/when it ever gets to the point you can test and certify programmers reliably the same way you do mechanical engineers, WITHOUT stifling innovation in the process, THEN you'll have reached that goal.
Today, it is nowhere near in sight. Every effort to responsibly certify programmers (and lots of irresponsible efforts) have all failed, or at best have done very poorly, for the simple reason that there is currently no science that allows you to validly do it.
I would go so far as to say that most programming "certifications" offered today are not worth the paper they're printed on.
Re: (Score:3)
Re: (Score:3)
The problems with software development are systemic in most environments currently. There is never enough time to figure out what doing it right m
Re: (Score:3)
In reality, the truth is its impossible for most people to write non-trivial programs without bugs. Just like its impossible for most people to consistently land airplanes without crashing. In air travel, 99.9% of those people are weeded out of pilot programs. In programming, they move on to the next project.
Part of the problem is that the programming profession hasn't had its professional renaissance like the medical profession had in the twentieth century. We don't train programmers to be skilled, effi
Re: (Score:3)
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
Re:what if... (Score:4, Funny)
To all programmers out there, I'll fix your bugs at 5x the rate you do, for a mere 2x your salary. I specialize in array overruns because you're an idiot, pointer misalignments throwing low-level hardware exceptions because you're an idiot, calculation errors due to incorrect operator precedence and casting at inappropriate stages because you're an idiot, and multithread bugs because you're an idiot.
Well, I'm an idiot, anyway. None of the sins you listed are commonly committed by me, however. In some cases they're impossible using the language and tools I'm presently using, but in most cases, because I've always been rather paranoid about the low-level stuff since I did a lot of OS internal work where that sort of thing could send an entire company home for the afternoon.
Not to say that I do bug-free work, just am more subtle in my bugs.
However, the last major corporate job I had, didn't want that level of quality and frequently dinged me for it. All they wanted was for me to "Git 'R Dun!"
It's not like they were a major financial institution or anything. Oh wait...
Re: (Score:3)
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)
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
Re: (Score:3)
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
Re: (Score:3)
Software development is just about the only industry where perfection is expected.
Re: (Score:3)
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
Re:what if... (Score:5, Insightful)
** on his own time, that is.
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.
Re: (Score:2)
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)
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.
Re: (Score:3)
It's a bad analogy because non-software engineers who do really creative work generally do have similar failure rates to software engineers. If you look at builders of original architecture they have to deal with fixing a lot of problems. Petroleum engineers have all sorts of inefficiencies and failures. Bridges that are in any way original are frequently known to fail. Let's stop comparing complex software applications to incredibly standardized roads.
Re: (Score:3)
"In software, a spectacular crash caused by a particular kind of bug isn't publicly analyzed and the entire software development industry doesn't pass new standards that proscribe avoiding that error in the future"
What is a spectacular crash in software? I hear what you're saying, but you're basically defining why we haven't had this level of introspection. Software just doesn't fail that catastrophically. Being unable to load the healthcare.gov website does not in any way compare to a bridge collapsing kil
Re: (Score:2)
There is, at least in Texas: http://www.tbpe.state.tx.us/do... [state.tx.us]
However, the vast majority of software will not need a PE license, just as the vast majority of construction does not need to be sealed. Its likely to be mandated in the future for things like avionics, control software, or large projects such as state level payroll systems, which will be interesting to watch.
Re: (Score:3)
That's not the same as requiring a PE to seal it though, mainly because software PE licenses are a new concept (I'm not actually sure that any have been granted yet to be honest, although they certainly will be granted this year). Even that's going to be interesting, because PE's typically seal a design, never an implementation - and its still a little grey as to which category software fits into. Are the specs sealable? Is the code? Its hard to see how the deployment of code could be, but I guess we'll
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.
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.
Must of been a non-union builder... (Score:2)
...if it was a union job, the employer would be paying twice.
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.
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).
Re: (Score:3)
"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.
Re:Builder = Business != Individual (Score:4, Informative)
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.
And its often the case with software that a large sale will include items such as insurance requirements, performance guarantees, and even source code escrow, to help provide a similar level of assurance.
Building code is not the same as building a wall. (Score:2)
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
Re: (Score:3)
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
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.
developers don't cause bugs, QA does (Score:5, Funny)
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. :)
The Builder is working for himself presumably (Score:2)
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.
We're in the pre-industrial era.. (Score:3)
..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
The client wanted it that way (Score:4)
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'
I'm no programmer, but... (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:3)
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)
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
Hmm... (Score:2)
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?
Time to polish up the old resume (Score:2)
It depends (Score:2)
Code is not Bricks (Score:2)
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)
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?
Nothing would get done (Score:2)
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.
Not quite true in either case ... (Score:2)
Easy (Score:3)
Says who? (Score:2)
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
Problem is with resource allocation / estimation (Score:3)
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.
many reason (Score:3)
Re: (Score:2)
It depends, but I say Nope.. (Score:3)
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.
Why is not there liability for programming errors? (Score:2)
Q. What time is it? A. Time for a new boss. (Score:2)
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).
When it comes to code, it's usually more like... (Score:2)
A wall is easy to define, but software is not (Score:2)
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
Depends on when the wall failed (Score:2)
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.
Obligatory Dijkstra (Score:3)
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.
It could work like that. (Score:3)
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... (Score:5, Funny)
Only if you're a contractor (Score:3)
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.
Your boss is an idiot. (Score:3)
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 (Score:3)
You buy the software, you buy the bugs (Score:3)
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.
The answer, in short, is "NO" (Score:3)
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.
Re: (Score:3)
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
Your Boss Might Be An Idiot (Score:3)
"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.
A good question (Score:3)
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.
Of course not... (Score:3)
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.
My bugs (Score:3)
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!
Re: (Score:2)
Exactly. $BOSS is an idiot. Everyone and everything has an error rate. Software development is well known not to be a perfect process. Even the very best developers create bugs. Your boss didn't hire some theoretical perfect developer, he hired you. If he's not happy with your error rate, he can fire you, but he can't require you to work for free just because you aren't as good as some theoretical perfect developer.
Re: (Score:3)
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 mult
Re: (Score:3)
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 do
Re: (Score:3)