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

Bizzeh writes "Today my boss came to me with what he thought to be a valid point and analogy. A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher. In most cases, he would have to replace those lower bricks at his own expense and on his own time. Comparatively: A software developer writes a piece of software. When bugs are discovered, the developer is paid to fix them by the employer and on the employer's time. I didn't know how to refute the analogy at the time, but it did make me think: why are bugs in software treated differently in this way?"

Re:what if...

[DaveAtFraud]

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

Capital vs labour

[TapeCutter]

The whole anaolgy fails miserably. The "builder" is a small bussiness, the coder is an employee. The builder's employee who fucked up the wall does not pay for it out of his own money/time, for the same reason his wages don't double when company profit does. An employee is not a one man company, nor should it be, any employer who tells you otherwise is trying to screw you.

Re:Guarantee

[Jane Q. Public]

"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:Guarantee

[smartr]

Nonsense, the builder's employee is analogous to the computer itself. Programmers are far above the low level work of brick laying. Programmers are more like experimental architects. Less experienced or simply more optimistic programmers will make more mistakes because they're constantly learning. One might further say that a programmer, who by trade is exercising the trade of "computer science", is in fact closer in position to that of a scientist. If scientists only got paid when their hypothesis was correct, no matter how many experiments were run, not much science would be getting done. If an employer does not understand this risk, they probably are not prepared to be doing business in the industry and might also want to double check their employee tax obligations.

Real life analogy

[Camael]

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.