Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

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

Soulskill posted about a year ago | from the 10-of-10-employed-developers-say-no dept.

Bug 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?"

Sorry! There are no comments related to the filter you selected.

what if... (5, Insightful)

Chadster (459808) | about a year ago | (#46223097)

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

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

TechyImmigrant (175943) | about a year ago | (#46223109)

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... (5, Funny)

Anonymous Coward | about a year ago | (#46223291)

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

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

Guarantee (5, Insightful)

Roger W Moore (538166) | about a year ago | (#46223401)

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... (2)

fl!ptop (902193) | about a year ago | (#46223113)

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

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

Re:what if... (4, Interesting)

DaveAtFraud (460127) | about a year ago | (#46223189)

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.


Re:what if... (0)

Anonymous Coward | about a year ago | (#46223121)

If the wall sags because the foundation is bad, you sue the guy who screwed up the foundation. It's not really a mystery.

Re:what if... (1)

SJHillman (1966756) | about a year ago | (#46223447)

It's also not really that simple. You can't always tell if the foundation is bad because of the materials had poor QA, the guy who poured it is incompetent, the guy who designed it didn't know what he was doing, or there was an as-yet undiscovered sinkhole right underneath the house. There's even times when everything is in spec, but it still doesn't work like it should.

Re:what if... (0)

Anonymous Coward | about a year ago | (#46223151)

What if the bug was the result of bad or incolplete requirements? Does the BA or business user not get paid for the time it takes to fix the requirements and subsequent code?

Re:what if... (1)

asmkm22 (1902712) | about a year ago | (#46223463)

I wonder if his boss would be willing to hire and train new employees that are replacing old employees, since he obviously didn't hire the right people the first time?

Re:what if... (4, Insightful)

asmkm22 (1902712) | about a year ago | (#46223471)

** on his own time, that is.

Bad Analogy (4, Insightful)

rjstanford (69735) | about a year ago | (#46223131)

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:Bad Analogy (1)

rjstanford (69735) | about a year ago | (#46223163)

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 (0)

Anonymous Coward | about a year ago | (#46223219)

A bricklayer is a bad analogy. But the quality of software has been a topic of discussion before. The question is why there is not the equivalent of a professional engineering license for software. A PE in another field would have to be tested to show that they are competent, would sign off on their work, and if it breaks they're liable.

Re:Bad Analogy (2)

tthomas48 (180798) | about a year ago | (#46223321)

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:Bad Analogy (1)

rjstanford (69735) | about a year ago | (#46223325)

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:Bad Analogy (5, Insightful)

Anonymous Coward | about a year ago | (#46223365)

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

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

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

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

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

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

It's called being an employee (1)

Anonymous Coward | about a year ago | (#46223133)

When a bricklayer who is an EMPLOYEE builds the wall, even if it's defective, he fixes it on the company's time. If he's a contractor, then yes, he fixes it (depending on the contract) on his own time.

bottom line: if you're in California at least, you could probably sue for your boss just THINKING about having you do work (whether new work or fixing your old own work) off the clock.

Re:It's called being an employee (1)

SecurityGuy (217807) | about a year ago | (#46223327)

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.

Your boss knows fuckall about construction (5, Insightful)

Anonymous Coward | about a year ago | (#46223137)

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

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

Re:Your boss knows fuckall about construction (1)

Anonymous Coward | about a year ago | (#46223407)

I don't know much about wall builders, but I've worked with more than a few pipeline companies (admittedly, only doing field tech work, but I've seen quite a bit). If, say, they told a welder to work for free to fix a bad weld or joint of pipe, I bet that everyone on the jobsite would quit (after their next paycheck).

Also, advice to the submitter: don't stick around a boss with ideas like that popping into his head.

Nonsense (1)

Anonymous Coward | about a year ago | (#46223139)

If I'm a doctor, and patients dies, should I return the money?

Re:Nonsense (1)

Anonymous Coward | about a year ago | (#46223283)

No, you get sued for everything you are worth, and your insurance company settles, so your rates go way up next year.

simple (0)

Anonymous Coward | about a year ago | (#46223141)

Because the market says developers don't have to. Supply and demand. If there were developers in supply than the current demand then pay would decrease and developers would need to start doing things like this. As it is developers are in a good position... obviously better than builders.

Re:simple (0)

Anonymous Coward | about a year ago | (#46223187)

btw, it's not clear if you're an employee or contractor. In the US, employees are never supposed to work for free. Even if they screw up. It's the law.

No... (0)

Anonymous Coward | about a year ago | (#46223143)

If a contractor is paid hourly, it is pretty common that they will count the hours it takes to fix any screwups that occur during the building process.

Shit happens, that's part of the job.

However, if they make many mistakes and cost the employer more money than other similar contractors, then they may not get the next job... or they may have to take a lower hourly pay due to their lesser quality workmanship.

If, on the other hand, the job is bid at a flat amount, the contractor eats any extra time it takes to fix the problems. Same applies to software development.

The real problem here is people who hire exempt, salaried software developers - and then expect them to work extra hard to "do their job"... If you, as a salaried employee, claim it will take you X number of hours to do a job, and fix the bugs, then it's your job to try and hit that schedule - just like the guy who bid the flat rate.

Must of been a non-union builder... (1)

JDAustin (468180) | about a year ago | (#46223145)

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

Builder = Business != Individual (4, Insightful)

shri (17709) | about a year ago | (#46223149)

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:Builder = Business != Individual (0)

Anonymous Coward | about a year ago | (#46223247)

I don't know about others - but I tend to write OK code when drunk ;)

Re:Builder = Business != Individual (2)

nospam007 (722110) | about a year ago | (#46223339)

"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 (3, Informative)

rjstanford (69735) | about a year ago | (#46223443)

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. (1)

Timmmm (636430) | about a year ago | (#46223153)

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 point is that is negotiated in advance, and no sane programmer would agree to fix all bugs for free.

Re:Building code is not the same as building a wal (2)

fl!ptop (902193) | about a year ago | (#46223315)

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

Sort of. If the wall is built in a cold weather climate, the mortar mix is different than that of a warmer climate. Some walls are built to hold a load from the top, others may be built to hold back a load from the side. In the latter case, you'd probably want to use rebar and concrete to fill the voids (assuming it's block and not bricks). The differences may be more subtle than code, but my point is not every wall is built the same way.

developers don't cause bugs, QA does (5, Funny)

RichMan (8097) | about a year ago | (#46223155)

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

The Builder is working for himself presumably (1)

SocietyoftheFist (316444) | about a year ago | (#46223161)

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.

Fire your boss (0)

Anonymous Coward | about a year ago | (#46223165)

Not only is it unethical to fix a bug on your own time, it's also illegal as well. Unpaid work is unpaid work, regardless of how you try to frame it.

Analogies (0)

Anonymous Coward | about a year ago | (#46223169)

Bugs are not always due to coding, incomplete requirements etc. Building a wall would regularly be looking to achieve the same result, using same tools with little variance. This is not the same as software development. As analogies go it's pretty bad.

not quite a direct analogy (1)

Isara (869637) | about a year ago | (#46223171)

Unfortunately, most software is so dependent upon other code that it's pretty difficult to find out where the problems lie before they get into a testing (or deployment *gulp* environment).

So, in this case, the wall-builder would have had to have known that the bricks at the bottom were rotten at the core and couldn't handle the strain, or that there was a cavern in the earth underneath the wall, or that the mortar was bad. One could argue that it's the builder's role to know these things in advance, but it gets more complicated if the landowner's environment is the one causing the problems.

We're in the pre-industrial era.. (2)

MpVpRb (1423381) | about a year ago | (#46223173)

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

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

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

The client wanted it that way (3)

codegen (103601) | about a year ago | (#46223177)

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?

False analogy (1)

Anonymous Coward | about a year ago | (#46223179)

If a builder builds a wall that falls apart his company will cover the cost of rebuilding the wall.
Maybe that specific builder will get fired.
No one will work on their off time and everyone still gets paid.
So suck it managers. In some countries they probably wont even replace the wall for you. (a certain country in south america where I lived comes to mind)

Maybe yes, maybe no? (1)

Tvingo (229109) | about a year ago | (#46223181)

If you are salaried then no, you shouldn't have to stay late or work weekends to fix bugs. If they aren't satisfied with your work production in your 40 hour work week then they should let you go and try to find someone better.

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.

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.

Re:Maybe yes, maybe no? (0)

Anonymous Coward | about a year ago | (#46223425)

Sounds like you're saying "yes, bugs should be fixed free of charge by the person who created them" in all 3 cases... you provided 3 scenarios where the developer gets the short end of the stick if they created the bug.

Just a quick thought... (0)

Anonymous Coward | about a year ago | (#46223183)

Writing code is developing (almost like R&D) something new, where as with building a wall is just copying something that has already been developed. The process, materials, etc for building a wall are all predetermined, and the final result should be of a certain known quality. If it is not, then it was most likely the builders fault, or faulty materials. If the materials were faulty, the supplier may actually be just as liable as the builder.

because it's not work for hire (3, Insightful)

hguorbray (967940) | about a year ago | (#46223193)

if you pay someone by the hour (or month) to write a document and there are typos, mispellings or factual errors you pay either the writer or an editor to take more time to make corrections.

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

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

-I'm just sayin'

The Contractor (0)

Anonymous Coward | about a year ago | (#46223195)

This is a bad analogy because the contractor would be required to fix it on his own dime, but the guy laying the brick would be paid.

I'm no programmer, but... (1)

arashi no garou (699761) | about a year ago | (#46223197)

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:I'm no programmer, but... (2)

rjstanford (69735) | about a year ago | (#46223475)

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.

Contractor vs employee (0)

Anonymous Coward | about a year ago | (#46223201)

You do not employ the builder as an employee - there is a contract to deliver a specific output within cost, scope, and quality requirements. The relationship between an employer and employee is different - an employee operates under the direct supervision of an employer.

Think of authors and journalists (0)

Anonymous Coward | about a year ago | (#46223207)

Successful authors and journalists have (or used to have prior to the gutting of the newsprint industry) a number of editors and copy editors look over their work prior to release.

Mistakes are inevitable in print media. Serious mistakes have corrections issues in subsequent revisions or in the "corrections" section of the paper. This is somewhat analogous to patching software.

Rather than building a wall, a development team is closer to running a newspaper.

Context (2, Insightful)

Anonymous Coward | about a year ago | (#46223209)

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.

Hmm... (1)

tthomas48 (180798) | about a year ago | (#46223211)

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?

The Pay Structure (0)

Anonymous Coward | about a year ago | (#46223217)

A coder is paid [essentially] by the hour to develop code. You don't own the code. You don't get paid by the job, line, or anything else. The same is true of the brick layer. His boss may be getting paid by the job, but not the guy laying bricks.


follow your analogy ALL the way (0)

Anonymous Coward | about a year ago | (#46223221)

A single thread / request would be a single brick. Then the wall you build would be, say the size of a region, if not a state. This wall requires regular maintenance in the form of tuckpointing by an entire full time team. The analogy stands, and technology, as usual, is just optimization of the same processes in the rest of the world, with small improvements in efficiency.

No. (0)

Anonymous Coward | about a year ago | (#46223227)

a) Your boss is wrong, the fault is with the shitty bricks the client specified and it's his cost and if he doesn't like that he can sue through small claims court and have a structural defect while he waits.

b) Code is far more complex than bricks, less interchangeable with far more interaction between it's parts. Brick 2 doesn't fall out because brick 65535 became lose, and no one ever asked you to change the colour of the bricks at the bottom of the wall or knock 4 more doors through the bathroom wall in case you really need to pee (but at the same time remove the toilet).

In short, due care and attention and a basic knowledge will allow you to build a wall that will remain unchanged for hundreds of years. Do the same thing with software and you would be a unique individual unlike any that have lived on earth before, and that's without taking into account a lot of bugs are failings in the compiler or libraries that you're building on top of, or the chip it's run on, etc, etc, etc.

Design Development (0)

Anonymous Coward | about a year ago | (#46223229)

It is called Design Development. If you boss does not understand this, then there are bigger issues at hand.

Time to polish up the old resume (1)

The_Wilschon (782534) | about a year ago | (#46223239)

Guess you should be looking for a new job. No point in sticking around to work for such a terrible boss.

Contractor vs Employee (0)

Anonymous Coward | about a year ago | (#46223241)

If the bricklayer is a contractor and is being paid by the job then his statement is correct. If the bricklayer is an employee then he gets paid to fix the wall.
If a developer is a contractor being paid by the job then the fix should be at his expense. If the developer is an employee then he should get paid to fix the software. Note that being paid by the job is a bad idea for a single developer who does not have the resources to spec the job and all the change requests and estimate and bill each.

Beta = bad - why do I need to enable JavaScript?

It depends (1)

evil_aaronm (671521) | about a year ago | (#46223243)

Granting the base premise, like a lot of other situations, it depends. Is this a syntax bug, or a semantic bug? A syntax bug should be caught in testing, unit or validation. A developer should be conscientious enough to avoid those. Semantic bugs are going to be more difficult. Did management or the customer change the spec after the code foundation was laid? If so, that can't be held against the developer.

Malpractice (0)

Anonymous Coward | about a year ago | (#46223249)

Call it what it is, malpractice. If you CAN sue, SUE! If you can't, get even. Too bad it goes against labor laws to do what you think would be fair.

You're only liable for avoidable problems (0)

Anonymous Coward | about a year ago | (#46223251)

The law doesn't compel you to do the impossible. Flawless software is science fiction, not state of the art.

Code is not Bricks (1)

Herkum01 (592704) | about a year ago | (#46223253)

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 write something and hope the specs were close. Should you be blamed if we ask you to add 2 numbers together and complains about errors when he uses strings instead?

If your boss is asking you to work on your own time because of something like this, I would find a new boss. He is just trying to pass the blame and you would be a sucker to accept it.

Fucking Stupid (4, Insightful)

cosm (1072588) | about a year ago | (#46223255)

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

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

In enterprise environments there are SLAs that cover this sort of thing. Why is this drivel on the front page? Somebody's first time discovering they can email scripts for their Joe's Home Programming business or is the editor-community here (he said sighing...) that detached from how enterprise development works?

Warranty? (1)

Neruocomp (513658) | about a year ago | (#46223257)

Following the builder analogy, at my university, there were issues with a new building's facade, so the builder came back and repaired it. But warranties also expire. This sounds a lot like maintenance contracts used when buying servers/software(eg Oracle). But as for 'blaming' a particular developer for the issue, couldn't you also argue that the QA team is at fault? What about those who wrote the spec? There are many people involved in building software and this is where the analogy breaks down.

Nothing would get done (1)

subanark (937286) | about a year ago | (#46223259)

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.

Just tell him... (1)

steve.cri (2593117) | about a year ago | (#46223263)

... to hire a bricklayer to finish his project.

Paid Software? (0)

Anonymous Coward | about a year ago | (#46223265)

What about Open Source Software? Simply reporting bugs is a thoroughly unpleasant experience. Some projects take months to acknowledge there even is a problem, and in special cases they spend a few more months passing the buck (blaming it on system/hardware/whatever). One of the reasons I stopped using Arch, bugs only get fixed when they hit all the major distros and their users file reports en masse.

No way (0)

Anonymous Coward | about a year ago | (#46223271)

This analogy stinks because software is far more complex than building a wall. Besdies the whole issue of what constitutes a bug, a deep and difficult question, in software, situations arise that cannot reasonably be anticipated like bugs due to external changes in the environment.

Brick walls are expensive (0)

Anonymous Coward | about a year ago | (#46223281)

That's why they use facades. Bricklayers are also independent contractors with insurance and licensing requirements. Not any jackass can build a wall, but I'm sure your manager doesn't see or respect your colleagues in the same way.

Wall builders are typically smart enough to join a union.

Your manager is an idiot and has no reason to manage anything more than a fry-basket.

False Equivalency (0)

Anonymous Coward | about a year ago | (#46223295)

Building physical structures, and writing code are not as analagous as they seem.

Gardening is a more apt analogy. If you paid qa gardner a flat rate to plant a flowerbed, you wouldn't hold that gardener responsible for future weeds unless that gardener were contracted to do the maintenance.

Not quite true in either case ... (1)

Old97 (1341297) | about a year ago | (#46223297)

If you are an employee, you don't have to fix bugs or bad walls on your own time. If you're are a subcontractor that may be expected by some. At my company when a contracting company (including a 1099 or individual corp) is on T&M and screws up - terrible design, incompetent programming, etc., we still pay them until we decide to end the relationship. The alternative is fixed price contracting or a form of "piece work", but that puts a big burden on our own incompetent and clueless managers. They'd rather keep paying than be exposed as useless overhead. Building contractors can't get away with that so easily and they have inspectors to assess quality so they can hold their subcontractors accountable for the quality of the work. Software is rarely developed using rigorous engineering methodologies and documentation, especially in business IT.

YES (0)

Anonymous Coward | about a year ago | (#46223299)

And also, they have to pay the company, for the opportunity to be part this great community. And do night shifts too.

Easy (2)

The MAZZTer (911996) | about a year ago | (#46223309)

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?

Says who? (1)

WalksOnDirt (704461) | about a year ago | (#46223313)

A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher. In most cases, he would have to replace those lower bricks at his own expense and on his own time.

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

It is the same for software development.

no analogy needed (0)

phantomfive (622387) | about a year ago | (#46223319)

There's no analogy needed. Tell your boss to find some other programmer who's willing to work for free; he won't be able to.
There's a big enough supply of programmer jobs in the world that no programmer needs to submit to that kind of work condition.

Really. Don't argue that one. Glare at him for a bit, then return to your computer. Distracting by things that matter in life, like programming.

Not a wall you're building (0)

Anonymous Coward | about a year ago | (#46223323)

Depending on your project, you're building anywhere from a building to a city, and a screw is bound to be misplaced. When that happens, the person who paid for the building can either sue (the equivalent of making too many mistakes and getting fired) or they can hire someone to fix it. If he feels otherwise, you can compel him to write a full program without any bugs on the first try.

Problem is with resource allocation / estimation (2)

pipedwho (1174327) | about a year ago | (#46223329)

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

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

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

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

Tell your boss to suck it (0)

Anonymous Coward | about a year ago | (#46223337)

Maybe you should use a little construction analogy of your own.
Schedule in more time for project delays and more costs for potential bug fixing.
If everything is done on time you get to keep the difference in time and money.
That's the way it works in construction after all.

Uhm. That's a bad comparison (0)

Anonymous Coward | about a year ago | (#46223347)

How can someone compare a brick layer to a programmer? Programming is an act of invention. The process of invention is a cycle of trial and error and you are paying someone to solve a puzzle. Solving a puzzle implies there will be problems along the way. Brick laying is a well known simple work type and very easy to estimate. I was actually a brick layer and then later in life switched to be a software developer :) As a bricklayer, I worked for a larger construction company and I would get paid hourly even to fix problems that happened as long as they were within the normal limits of expected problems. The construction company I worked guaranteed their work to their customers. A more accurate comparison would be: the builder being 'microsoft' building windows vs a company like 'granite construction' building walls ;-) Both guarantee their work and pay their employees to fix problems whether they are code-related or structural. I get free updates for problems in either case.

many reason (2)

n1ywb (555767) | about a year ago | (#46223349)

  1. Most software projects are reasearch and development; buiding something new that's never been built before; hence there's a lot of risk. It's not like a wall that people have been building the same kind of wall for thousands of years. Risk costs money. The only question is who's going to pay for it. Hint: the boss, unless you're stupid, or you have some sort of equity you want to protect.
  2. If you're an employee, the boss has two choices; pay you to fix it, or fire you. Construction and programming are the same in this regard. Maybe he can take it out of your salary, I dunno, might depend on emplyment terms or state law. But typically he cannot compel you to work for free; that's called slavery.
  3. If you're on contract, you're only obligated to fix your mistakes to the extent that the warranty clause demands it. No warranty clause no fixie. The boss may be able to terminate the contract or just not contract with you again, his choice. Your choice if you want his buisness bad enough to fix it for free. Again, construction and programming are the same in this regard. If you do have a warranty clause you will typically bake your own cost of fixing your own bugs into your bid and or hourly rate so it's still not really free for the Boss, your bugs still cost him money.

Re:many reason (1)

n1ywb (555767) | about a year ago | (#46223409)

Of course if you're OT exempt salaried then you get to work as many hours as your boss says, or quit, or be fired. But market rules still apply in the big picture.

Employee or Business? (1)

el jocko del oeste (2450190) | about a year ago | (#46223351)

The analogy is seriously flawed.

If the builder is running a business and has contracted to build a wall, it may be that the business is obligated to fix problems at no additional cost (depending on the terms of the contract). But the situation is entirely different if the bricklayer is an employee. I don't think that many builders can get away with forcing their employees to perform work on their own time and at their own expense.

Similarly, if a software developer is running a business and has contracted to build a piece of software, there may be contractual obligations for the software business to fix errors at the business' expense. But I'm unaware of any instance of a software developer who is an employee being required to fix errors on the employee's time and at the employee's expense.

It depends, but I say Nope.. (2)

bobbied (2522392) | about a year ago | (#46223353)

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

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

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

You can do what you want though.

If... (0)

Anonymous Coward | about a year ago | (#46223357)

If I'm an employee that's not getting paid to work for the company, I find a new job.

If I'm on contractual agreement, I already provide bugs guarrentee, but I usually charge more then the "real" hourly rate to cover for that.

Why is not there liability for programming errors? (1)

mi (197448) | about a year ago | (#46223359)

A wider question is why is not there any liability for programming errors? All end-user licenses (both free and otherwise) explicitly renounce any such — and we accept it. Maybe, we should not [acm.org] ...

Q. What time is it? A. Time for a new boss. (1)

theodp (442580) | about a year ago | (#46223361)

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... (1)

Max Threshold (540114) | about a year ago | (#46223369)

If the boss demands that the builder builds the Great Wall of China in a week, he has nobody but himself to blame when it falls over.

Dilbert - "I'm gonna write me a new minivan..." (1)

thejonz (1344933) | about a year ago | (#46223385)

This reminds me of one of my favorite Dilbert cartoons - "I'm gonna write me a new minivan this after-noon!" http://dilbert.com/strips/comi... [dilbert.com]

huhwhaaaat? (0)

Anonymous Coward | about a year ago | (#46223387)

The analogy is pretty stupid, if you ask me. Perhaps the better analogy is a writer - and an editor. The editor makes more for fixing the mistakes (at least in a news/magazine setting) than the writer may make for the original authorship.

And, the bricklayer is not going to repair work on his own time. They may sue the mortar company, or the brick manufacturer, but GIGO still applies.

Clause in CGI's contract (0)

Anonymous Coward | about a year ago | (#46223393)

"Work submitted is deemed accepted if not rejected within five days in writing."

They did the ObamaCare site that has brought healthcare to millions, and are the absolute best at writing contracts to protect themselves. All of their contracts with my employer contain the phrase above. It's brilliant. They shovel so much crap at us so quickly that there's no way for us to reject within five days so we always have to pay for rework.

A wall is easy to define, but software is not (1)

Brama (80257) | about a year ago | (#46223395)

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 will likely change while you are implementing it.

In short: Complexity is several orders of magnitude more difficult. If it were as easy as brick laying, you'd be replaced by a machine by now.

re (1)

skyeagle53 (1801680) | about a year ago | (#46223397)

In that case the employer would be the builder and you would still be the hired help.

Nope, he's wrong (0)

Anonymous Coward | about a year ago | (#46223413)

Of course bosses want you to work for free for any reason they can think up.
There's a Fair Labor Standards Act that pretty much says "No" to that.

If your employer pays you to make it... (0)

Anonymous Coward | about a year ago | (#46223419)

...then he pays you to fix it too. Whether it's brick walls or software

I always charge for fixing my own bugs (1)

n1vz3r (3533981) | about a year ago | (#46223423)

Probably because in 90% cases I'm the only developer (I work in really small company). I'm fine with this because I tell myself that if I would try to create better (bug-free) code it will take more effort - and still result in almost the same cost. So the resulting price ((x + 0) + y) is the same (x before the bug was found, y after it was fixed) as if I would develop the feature initally bug-free ((x + y) + 0). Ok, probably it's not great idea to tell that to the customer, but it's better for dealing with my conscience than nothing :) The only difference between two approaches (create fast, then fix, or create slowly, then don't fix) is having an irritated client (but in second case he will be irritated by 'slow' development, so it's questionable).

Simple. (0)

Anonymous Coward | about a year ago | (#46223431)

It is because you cannot insure software but you can insure brick walls. The bricklayer can get insurance to cover him for cases of bad workmanship. Try getting insurance on data. No insurance company will touch you.

Depends on when the wall failed (1)

medv4380 (1604309) | about a year ago | (#46223435)

Under the constraints of the analogy sure. If a developer ignored an obvious defect, bricks falling out the bottom, early in the process then sure the developer should repair them immediately. However, there is no such thing as a perfect wall or perfect house. You inspect the wall, or house before you sign for it, and if you agreed that it meet your expectations then you pay for it, or whatever the contract required. Some houses come with insurance that in case a defect is discovered within a grace period that it will be corrected, and that's payed for by the insurance. If it is outside the grace period of the contract, or insurance, then the customer is going to have to pay for any future defects found. You can't expect someone to build an earthquake proof home that covers every situation unimagined.

Having laid bricks.... (0)

Anonymous Coward | about a year ago | (#46223459)

Building a brick wall is a 'known' art; the requirements for a good wall are in the condition of the building site (Is the ground underneath firm or soft...), the specifications for the mortar (which can change as the weather changes, the condition of the bricks...), the thickness and height of the wall, all requirements that are well known and documented.

Software, however, isn't bound by the same limits - it's as if the bricklayer/Mason not only had to make the bricks on the spot, but haul in the underlying earth as well, had to burn the lime to make the mortar, dig the sand and haul the water from a well he dug himself. The Bricklayer has to hope the the supplies he'll be using are of decent quality; he has little control over what the customer will provide; and if the supplies provided are not quality, there's only a limited amount the bricklayer can do to adjust for the deficiencies.

When a wall is being built, the number of bricks needed, the amount of mortar and grout are calculable, the bricks themselves will be of known quality, and the ground underneath will be prepared for the wall before the first foundation layer of mortar is placed to bed in the first brick. The Bricklayer implements an established plan; his creativity is in adjusting for unexpected small problems, not in changing a wall into the beginnings of a building.

This is entirely different from writing code; which is closer to writing a novel. Imagination is teased and twisted into words and images; and the programmer and the QC tester act as writer and editor, revising and rewriting pages of dialog, establishing themes and plots. Eventually, the 'Novel' is finished, and the entire software package is ready for the 'Readers' - those who will use the program.

Bricklaying v writing; it's not a subtle difference.

The manager is responsible, to start (1)

quietwalker (969769) | about a year ago | (#46223461)

Let's assume the programmer is average. They write some good code, some not so good, they have a certain bug rate. We have to assume that even the best programmers introduce bugs here and there. If you assume that no bugs will be created, or will develop later on - you are not fit to be a manager. Bugs happen.

Knowing that, a good project manager is going to create a system with peer review, with automated and manual testing, both unit and functional, frequent project sanity checks and of course, reasonable timelines and room in the schedule for refactoring and teardowns, not to mention some amount of signoff from those who okay'ed the project and approved each step.

If they won't provide that - it's on them. If they can't, it's those above them, and so on. That's the way it works; those above you in the chain need to provide an environment in which to excel, if they expect excellent results.

The downside, of course, is that it costs time and money, even if you start with exceptional people - not just average ones.

Testing takes half a project's time and money (0)

Anonymous Coward | about a year ago | (#46223477)

I don't see why you'd have to do that on your own time, it is part of the job, and as such you should be paid for it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?