Posted
by
Soulskillon Tuesday February 11, 2014 @06:49PM
from the 10-of-10-employed-developers-say-no dept.

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

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.

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.

You are exactly right because at a big enough scale, the builder simply can't absorb the losses. So whatever you extract for a promise from the builder, it doesn't matter, because their is no more money.

Even when "bonded", the amount of the bond can be insufficent. Then what?

That's why essentially every big government job has overruns and the people causing the overruns "pay for it", but not really. The contractor's only line of business is government work. Paying a fine or the cost of the overrun means that the next contract has that much more built in to pay the risk premium.

In the end, this type of scheme is just that a scheme, to shift risk from the party that stands to ultimately profit to a bit-player. It can only go on for so long.

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

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.

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.

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

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

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.

The builder (or builder`s company) is also generally licensed and bonded. Most modern software shops have pretty much given up on software engineering and jump randomly from fad practice to fad practice with almost no maturity or consistency. Something as rigorous as following standards, licensing, carrying insurance... their heads would explode.

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.

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.

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 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.

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.

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.

"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.

Yet if someone takes a sledgehammer to a wall and it fails, it's the fault of the sledgehammer or the person using it. But someone passes bobby tables to the database, and it's the fault of the programmer for not predicting the sledgehammer. Of course, input checking should be done, but the interesting point is the blame.

Actually it is exactly like the medical profession. There are also a great number of doctors that do no more than what a medical book tells them and just try one thing after another based on the list in a particular medical text they have been reading. As a person that had a problem 2 decades long and finally found a doctor that did a bit of thinking I know.

The problems with software development are systemic in most environments currently. There is never enough time to figure out what doing it right m

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

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

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...

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....

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

An even bigger problem is that with software, we don't get to just say "Close Enough". If you look at any building, bridge, wall, whatever, you will find huge numbers of defects. If the bridge doesn't fall down we say "Close Enough". With industries like medicine, standards are even looser.

Software development is just about the only industry where perfection is expected.

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.

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.

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").

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 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.

"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

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.

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

"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.

While influential unions are infamous to a near mythical degree for protecting mediocre tradesmen, their real strength lies in the ability to bottleneck the number of skilled tradesmen for a particular task in a given location.

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.

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

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.

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

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 blo

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.

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.

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'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.

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.

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

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.

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

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?

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.

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 r

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.

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.

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.

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.

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.

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.

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]...

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

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

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

When a builder builds a wall, all the factors are known for what the wall needs to endure. Weight it must support, elements and temperature it will be exposed to. The builder should know how to mix mortar and the steps involved with building a wall as he has probably done it many time before. If bricks are falling out, he has made a mistake, too much water in the mortar, too cold to work, something a more experienced worker would not have done and known about.

When a developer writes software, all factors are not known. Each piece of software is unique and designed to meed the clients needs. When bugs are discovered, they are factors that were never originally considered possible. People with names longer than the character field, leap seconds, changing daylight savings hours, operating system changes, network growth, hardware upgrades. Regardless of the developers experience, no one will be able to account for these unknowns and how new code for new features will interact with older code. Bugs usually are not from screw ups but from changing factors beyond anyone's control.

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.

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.

And only if the software fails to deliver on the specifications laid out in the contract. If it crashes when they try to use the software on a different dataset than the contract specified, that's not your problem. If the software doesn't perform as per the contract, then yeah the onus is on you (the contractor) to fix it. If you've already been paid for the job and used up that money, then yeah you need to fix it on your dime.

If you're an employee though, then there is no distinction between your work and the company's work. They are one and the same. If you deliver buggy code, the company delivered buggy code, and the company has to fix it (whether it be by telling you to fix it, or reassigning/firing you and getting someone else to fix it). Same reason the company is liable if an employee screws up and causes a fire which burns down an apartment complex.

Assuming you're an employee (if you're a contractor, technically you don't have a boss at that company - having a supervisor who can tell you what and how to do your job makes you an employee per IRS definitions), you can turn the argument on its head against the boss. Since he hired you and was responsible for managing you to produce the required bug-free code, if you fail to deliver it and refuse to fix it on your own time, then per his reasoning it becomes his responsibility to find someone who will fix it, and he has to do it on his own time and pay for the new hire out of his own pocket.

Software bugs are not caused by developer incompetence. They are a natural result of iterative development, where you write code, test and adjust it until it is done.

The brick wall analogy is completely nonsensical. When you are done building a brick wall, you can tell that it is done. There are no edge cases, requirement changes or memory leaks that can unexpectedly make it fall over.

If you are guaranteeing the perfect correctness of your software's first version with your own time, then you're not really a salaried employee. You're selling finished software and an unlimited support contract - and compared to those standards, you're undercharging pretty heavily.

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.

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

"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.

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 latest bugs are along the lines of:Me: Here's the most rough proof-of-concept, prototype implementation.Mgr: Ship itMe: 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!

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.

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

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