Slashdot Mirror
Ask Slashdot: Should Developers Fix Bugs They Cause On Their Own Time?
Bizzeh writes "Today my boss came to me with what he thought to be a valid point and analogy. A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher. In most cases, he would have to replace those lower bricks at his own expense and on his own time. Comparatively: A software developer writes a piece of software. When bugs are discovered, the developer is paid to fix them by the employer and on the employer's time. I didn't know how to refute the analogy at the time, but it did make me think: why are bugs in software treated differently in this way?"
developer's B bug only existed because of developer's A bug? Who fixes B's?
If a bricklayer, working for a wall-building company did this, then he'd be paid his normal wage to fix the wall (or fired if it was an egregious enough problem).
The wall-building company itself may indeed fix the wall gratis, but a certain amount of re-work is already baked into their bids. That's one of many, many reasons why companies bill out workers at 2X-3X the amount that they pay them (see also taxes, offices, holidays, paid downtime, &c). Its a cost of doing business for the company, not the employee.
If you're a 1099 contractor then I'd say that if you were working hourly it'd be the same situation as if you were an employee; if you'd bid the project as a project then I'd expect you to deliver it properly functioning, but again I'd also expect that your bid would have accounted for some possible rework.
You're special forces then? That's great! I just love your olympics!
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.
"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.
If I'm a doctor, and patients dies, should I return the money?
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.
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.
...if it was a union job, the employer would be paying twice.
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).
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.
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. :)
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.
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.
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.
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.
BOOP!
..of software development, and even the best of us aren't very good at it
If there was a foolproof procedure to guarantee bug-free code, and only the lazy or incompetent produced bugs, things would be different
Unfortunately today, a talented, competent developer, using best practices, always produces bugs
What if the boss told him that he had to use these cheap thin bricks. He told his boss the bricks wouldn't work but the boss insisted that he use the inferior bricks. What then?
Atlas stands on the earth and carries the celestial sphere on his shoulders.
If 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)
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.
Nothing i have to say is worth saying.
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.
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'
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.
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.
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.
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.
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.
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?
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.
Mike
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.
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.
It is called Design Development. If you boss does not understand this, then there are bigger issues at hand.
Guess you should be looking for a new job. No point in sticking around to work for such a terrible boss.
SIGSEGV caught, terminating
wait... not that kind of sig.
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?
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.
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.
The law doesn't compel you to do the impossible. Flawless software is science fiction, not state of the art.
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.
Either your manager is an idiot or you are misinterpreting his analogy. The business entity that causes the defects pays for the defects if they are within the terms of the contract. The builder is a business entity (S Corp or LLC, etc), just as much as XYZ Co. selling Desktop Bullshit 5. The employees of the business are generally shielded from mistakes the business makes. This is not unique to software development. A flaw in a Boeing 777 does not come out of the paychecks of the engineers that built it. They are either fired/retrained/retained for the re-engineering project, management is fired (or today promoted), or contracts are dropped/re-worked, and the work is redone on company/business entity dime. The same company that built it will be the same company that pays for fixes.
If I paint 'ole Ms. Gladys fence and miss a post, going back and "doing it on my own time" is trivial in terms of time-cost. But if my corporation writes an enterprise HR system for managing her egregious cat collection, it is my corporation that will fund the bug fixes for an erroneous bug that miscounts turds per feline. That cost of doing business will come out of my corporation's margin, not my employees paychecks.
In enterprise environments there are SLAs that cover this sort of thing. Why is this drivel on the front page? Somebody's first time discovering they can email scripts for their Joe's Home Programming business or is the editor-community here (he said sighing...) that detached from how enterprise development works?
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
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.
Physics is like sex. Sure, it may give some practical results, but that's not why we do it
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.
... to hire a bricklayer to finish his project.
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.
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.
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.
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.
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.
Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
And also, they have to pay the company, for the opportunity to be part this great community. And do night shifts too.
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?
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.
a,e,i,o,u and sometimes w and y (at be if of up cwm by)
Sort of. If the wall is built in a cold weather climate, the mortar mix is different than that of a warmer climate. Some walls are built to hold a load from the top, others may be built to hold back a load from the side. In the latter case, you'd probably want to use rebar and concrete to fill the voids (assuming it's block and not bricks). The differences may be more subtle than code, but my point is not every wall is built the same way.
When you recognize love in another and realize how precious it is, everything else seems so insignificant.
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.
"First they came for the slanderers and i said nothing."
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.
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.
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.
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.
-73, de n1ywb
www.n1ywb.com
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.
If you where working in any other industry, you'd get paid to do rework. Programming *should* be the same.
Problem is that it sometimes doesn't work out that way. Programmers are usually "Salary Exempt" in the USA, which means that if your bug breaks something and schedule is suffering, guess what? You fix it but you don't get paid more to do that. Sometimes that means burning the midnight oil during the nights and weekends. The same thing happens if you fall behind schedule. More hours, same pay.
This is the same question as "Should programmers get paid for over time?" Should employers be allowed to expect their salary workers to put in more than the standard work week? And for me, the answer is "it depends". If an employer is being flexible with me and my hours, I'm going to be flexible too. If you demand I'm in the office from 8 to 5 without fail, or suffer the consequences, don't expect me to stay outside those hours. If you are flexible about arrival and departure times, I don't mind working a extra, especially when you reach the critical phases of some project. But this should be the rare exception, and not the rule. When it becomes the rule, I'm going to start looking for other work if they do not cough up some kind of reward for extra hours.
You can do what you want though.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
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...
In Soviet Washington the swamp drains you.
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).
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.
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...
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.
"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 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.
In that case the employer would be the builder and you would still be the hired help.
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.
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.
...then he pays you to fix it too. Whether it's brick walls or software
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).
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.
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.
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.
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.
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.
You mean you never reuse the same code, or use a pattern of progress to build code? It's completely chaotic? No, of course not.
Interestingly, when you build a bridge of a skyscraper, and your part fails (for some reason - nail pops in drywall, paint doesn't adhere tot he steel, the road surface is too rough) you redo the work for free. Now, that's the corporate "you" not the personal you. The person making the bid covers it
(subcontractor, contractor, consultant, whatever), not the employee generally. And, if the architect or engineer designs it wrong and the plans don't meet code - they generally are required to redesign it for free. There are even some contracts which are price dependent - if the estimated cost of the project exceeds the budget the architect has to redesign it for free (analogy: you write code and it takes too many compute cycles/doesn't run of reference hardware).
As for payment, cost overruns which are the result of poor or incomplete workmanship (bugs) are nearly always born by the person doing the shoddy work, never the client (unless the client decides they want to pay for some reason, or are too removed from the work to realize they've been double charged).
Although I've known contractors to make employees fix screw ups on their own time, it's generally the company that bears the burden of the repair costs - so the OP should have said that, had he been contracted for a fixed fee to complete the job, yes - up to a limited warranty period; as an employee his contract is to perform services at an hourly (or weekly or yearly) rate. The corporation pays the employee a far lower wage than the equivalent hourly rate they receive for the product, because they take those risks.
Is it just my observation, or are there way too many stupid people in the world?
If the developer had sufficient time to thoroughly test his code and failed to do so, your boss may have a point.
However, if the timeline was defined by someone other than the developer and did not allow sufficient time to test all cases, then bugs are not necessarily the fault of the developer.
Case in point: I used to write code for a major telecom equipment manufacturer. In order to execute all possible test cases for some of my projects, I would have required 5 years doing nothing but testing. At that time, we had semi-annual delivery dates (no exceptions). As you can imagine, no way I could test everything. Definitely not my fault when bugs were found. Didn't feel the least bit of guilt about bugs.
If you want bug-free software, you must be willing to pay the price. If you won't pay the price, don't blame the developer.
A boss Is tasked with keeping his employees productive. He begins to cause them to worry about things like unpaid time. A large number of them up and leave. Should he pay the cost of talent acquisition and/or training for new hires to replace them?
When a builder builds a wall, all the factors are known for what the wall needs to endure. Weight it must support, elements and temperature it will be exposed to. The builder should know how to mix mortar and the steps involved with building a wall as he has probably done it many time before. If bricks are falling out, he has made a mistake, too much water in the mortar, too cold to work, something a more experienced worker would not have done and known about.
When a developer writes software, all factors are not known. Each piece of software is unique and designed to meed the clients needs. When bugs are discovered, they are factors that were never originally considered possible. People with names longer than the character field, leap seconds, changing daylight savings hours, operating system changes, network growth, hardware upgrades. Regardless of the developers experience, no one will be able to account for these unknowns and how new code for new features will interact with older code. Bugs usually are not from screw ups but from changing factors beyond anyone's control.
On the cruelty of really teaching computing science (EWD 1036)
Computer code is not bricks. It's completely different. So, your analogy based on bricks is not valid.
There was a better analogy I read somewhere. Programming is like building only if you're in some insane universe where you make one little slip-up and the entire structure turns into a black hole. But I don't remember who wrote that.
Have a nice time.
The problem is that when you entered into a contract (either with a customer or an employer), chances are this kind of mechanism wasn't stipulated. If ti were, then they would have presumably had to pay you a much higher salary to get you to agree.
Any reasonably complex software is a product that is with almost certainty going to contain bugs. If you are willing to be on the hook to fix every future bug discovered for free, you'd better charge enough up front to make this deal worth it.
Tell your boss he should be fired. If he's going to make bad analogies, they should at least involve cars.
This is my signature. There are many like it, but this one is mine.
In most cases the employee signs an agreement that indicates that all source code produced by a developer is the sole property of the company. As this is most likely the case, even if the developer created the defect (knowingly or unknowingly) the source code belongs to the company. Thus the developer is fixing company code not his own code. The only way that the developer should be fixing his own defects on his own time is when the company is buying the source code directly from the developer which means that the developer is not an employee of the company. A second point is that there are often in place agreements that indicate that every idea thought of by a person are the "Intellectual Property" of the company. Since the defect was a thought in the developers head as an idea, the company by agreement owns the thought or idea that generated the defect rendering the company responsible for the defect. Another argument that can be used in defense of the programmer is that in some cases the manager/supervisor has specifically stated that the code must go out to the customer within a specific time period and the programmer is obligated to send out the code despite any and all defects. In this case it can be argued that the manager/supervisor is directly responsible for the defects in the code due to time pressure. Those are my arguments against developers having to fix defects on their own time.
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 a lawyer messes up, who pays? The client.
If a doctor messes up, who pays? The patient.
If a tax adviser messes up, who pays? The schmuck.
So, if a programmer messes up, who should pay?
You don't have a contract? You don't have one that details how major and minor bugs will be treated? Then you should pay whatever hourly rate you agreed to for the developer to fix these bugs. If you worked up a contract that also included responsibility for the developer to fix his/her bugs, then the developer could have bid accordingly, taking into account that they may have to spend additional time guaranteeing their work for a certain period of time, under an agreed period of circumstances.
For the home builder analogy - home builders are subject to a certain amount of QA through testing and inspections. Sometimes the testing and inspection is performed by 3rd parties, or even city/government agencies. So in your analogy, if additional parties signed off on the wall - who is responsible for it becoming defective?
If your development contract was determined not to require proper testing, unit testing, load testing, etc. - or it was just not considered by the person offering the contact, then who should be pay for the fixes?
Developer Dave: Here's your wall, just the way you wanted it! :kicks wall: GREAT! Look's great, thanks Dave, here's your money as agreed!
Manager Mike:
^ Contract is complete. If the wall falls down tomorrow, Mike is SOL.
Have a good contact with proper testing, and defined milestones.
Yeah sure I'll fix it on my own time. And by "my own time" I mean if and when i feel like it. Otherwise, I'm getting paid.
As long as that "my own time" is during work hours and I am being paid for it.
If employers want to start being assholes, employees need to start being bigger assholes back.
Do not look at laser with remaining good eye.
... if he wants to be paid only when each employee under his direction is 100% satisfied in their employment. See how long that shit flies.
Which has more power: the hammer, or the anvil?
Tell your boss this. If a builder were to makes multiple changes, and those changes effected a good wall, he should expect to have "change orders" submitted. That would mean he would be billed for further services. Your original code may have been fine when you wrote it, but when it changes it could effect what was originally written.
i have no sig
Building something to a existing design is a reasonably mechanical process. There is the issue of workmanship, but assuming it is a quality builder the building will be completed and stand correctly. If however a building was not designed correctly and collapsed due to a design failure you would not blame the builder. Designers make their 'mistakes' while designing. It is a process of exploration.
Software development is not at all like the mechanical construction according to an existing design. It IS design. You are bound to go down false paths and blind allys. The design process is one that involved exploration through the space I call 'AppLand' - the state space that is represented by all possible computer programs. Computer programming is about navigating through this space. Sometimes you make a wrong turn and end up on the bank of a river. You need to build a bridge or walk downstream a little to find one.
However, there is a matter of quality; that you should implement quality assurance based on unit tests, code review, functional testing and stringent disciplines to ensure that released software is fit for purpose. You can't avoid making mistakes and rework in the development process, you are exploring the state space; but you can make sure you don't end up in the brambles and thorns; that is finding yourself somewhere where the program just doesn't work.
I've been writing my book "Exploring Appland" for about ten year now...
Software has bugs. Get over it.
This is just another manager trying to get free work out of the staff.
To hell with leeches like him.
I do not fail; I succeed at finding out what does not work.
The analogy is flawed.
Bricks are measurable, "fixed" components that behave in predictable ways. It is also a process that is highly repeatable - laying one brick is much like laying the next.
Software is not. It is dependent upon a much larger number of variables not the least of which is probably said boss changing his mind (and thus the specifications on which it is built) as frequently as the wind shifts.
Also, "bugs" are often nebulously defined. An end-user/boss' "bug" may actually be an enhancement since the functionality in question was never specified in documentation/discussions. If the bricklayer was told to build a four foot high wall and is later told to extend it to ten feet; then warns the customer the foundation may not support the weight; but is told to "make it work" (cough, cough Mr. boss) this is not the fault of the bricklayer.
A "bug" may also stem from something a developer may not be aware of, or cannot control. For example: JavaScript behavior in one browser may differ from that in another. It is not the fault of the bricklayer if the brick manufacturer put together a crappy batch, or the mortar manufacturer botched the cement/lime/sand mixture.
You can give him an option to hire a builder to fix the piece of software in question. :)
If he is satisfied by the results he can continue that path and outsource the entire development team
Not construction. A manager that insists to manage a R&D project as a construction project is going to have a bad time.
I don't know about you, but I find that most contractors doing open-ended projects get paid time & materials, including their time & materials when they screw stuff up...
You break it, you fix it. You don't fix it, I break you.
Your refute should have been to ask him if he would like to try that out himself. It would be particularly good to see an entry-level (the manager, assuming he does not have a technical proficiency) try to "learn" all the stuff they don't teach you in school the first two years of his career in a development role, and see how much extra time he spends fixing bugs.
There are better ways to incentivize programmers to reduce bugs, and this is not one of them. I would say the best incentive for a programmer to do a good job is that they want to advance in their career and/or be valued higher.
Having done both for 30+ years, I'll have to correct you.
There is no more ingenuity required by expert software development than is required by expert masonry.
In fact, the number of valid but unique combinations of architectural elements a mason may be called upon to use is probably far greater than the number of valid but unique combinations of code syntactica available to the programmer.
Obligatory XKCD I guess. Everybody thinks the job they've not done is easy. I'm guessing you could not tell me when to use hollow bedding, or how to adjust slaked lime putty for the acidity of stone under field conditions?
There are a lot of bad masons and bad programmers, of course. More than good ones, in both cases......
Being reasonable can provide more profit. But if you're compelled, I charge by the hour, if you change your mind; no problem.
A contractor gets paid for a job. The contractor has to calculate the chance of his own error and how much it would cost him to fix it into his bid.
You are either hourly or salaried. You get paid a specific amount for a specific amount of time given back. I'm that way to... and if my boss wants me to spend the day washing windows, I'll do just that. My productivity is his problem, and if I'm not productive or produce too much error he needs to fire me. If he wants a contractor he's welcome to go get one, but contractors cost a hell of a lot more than my salary does.
All bricklayers will eventually make mistakes, but there are many different kinds of mistakes. There are big mistakes, little mistakes, infrequent mistakes, and recurring mistakes. A skilled boss would not insult and risk losing his most valuable and productive bricklayers who make minor and infrequent mistakes by insisting that they patch up problems on their own time. If he did, those bricklayers would tell him that he doesn't seem to understand the range and relative importance of mistakes that can be made in his own industry, and they might go work elsewhere. Similarly, a skilled boss would recognize major recurring mistakes, and rather than be weird about it and ask the bricklayers responsible to come in and patch them up on weekends, would just get rid of them if they were costing too much money in the final product.
A boss in charge of a software development project should know - had better know - that there is no such thing as bug-free programming. The recipe for software production includes specification, design, implementation, testing, and review and reiteration of some of those steps. There will be bugs because there are always bugs. Ideally, you find and fix as many as possible during implementation and testing, but if your boss wants a situation where he's not responsible for any costs of fixing bugs after the product ships, then he's going to need to take the contract approach, where an outside software house creates the software and a contract that very precisely defines what constitutes a bug that needs to be fixed at the contractor's expense after the product ships is signed by both parties. That's expensive. If your boss wants programmers to fix bugs for free after the product ships that his own testers didn't find prior to shipping, then he should probably be in a different line of work.
Sounds to me like the OP's boss is just trying to find a way to pay his software engineers/programmers less money while making them do more work. It also sounds like this particular boss doesn't know how to do the job of the people he's managing and therefore doesn't understand the problems they can be faced with. Unexpected things happen, and playing the Blame Game instead of focusing on fixing the problem is not only counter-productive, but terrible for morale. Seriously, I think it's better to fire someone with a consistent pattern of screwing things up rather than punishing them constantly, which is what this could amount to.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
This isn't difficult. Employees get paid for their time. Brick-layers and programmers alike. The brick layer doesn't fix the wall for free. The bulider pays the brick layer by the hour to fix the wall. The owner doesn't pay the builder because the builder is contracted by the owner whereas the brick-layer is employed by the builder.
And this all makes sense. Since the choice of brick quality is made by the builder, the builder is accountable for fixing it.
Same goes for the software programmer, whose employer chose the platforms and the deployment schedule. The programmer gets paid to work. The quality of the work doesn't affect the pay at all -- just the odds of future employment.
For the record, I own and operate a web development company, for 21 years now. Bug fixing is always free to the client for the life of the project. I hate it when dumb employees make stupid mistakes. But I don't get to withhold their payment. I do get to fire them though. And I do get to engineer a platform that requires fewer employees. And I do get to choose clients and projects that don't require me to have employees do anything at all.
So, to answer your questions directly, there is no difference between software bugs and wall bricks. The only question is whether or not you contracted the programmer or hired the brick-layer.
Did the server crash ? (500 Internal Server Error)
Did you just kill the UAT daily build ?
Was it a typo ? (bad copy-paste, missing semi-colon or similar)
Was it a bad configuration issue ? (you put dev config into UAT or prod by mistake)
If it's none of the above, then it's not your fault and it's fully billable.
Most people would considers: new feature, vague requirement, vague specification,
bad interpretation of requirements or specs as bugs, it's not, it's called development.
For example, not covering XSS or CSRF attacks is considered a security bug,
or you could say that you did not implement that part yet,
since the website if for Intranet use only, which one is it?
Another example, your software only covers text that is plain ANSI English
and throws out errors if you insert French, Spanish, Hebrew, Chinese, Japanese or Latin1 or Unicode characters,
is it broken, or was it explicitly spec'ed out earlier
or not implemented / not supported yet ?
Or who pays for the bug which come from the underlying OS?
You are being horn-swoggled by a boss who is confusing two types of contract: A builder will _not_ fix the wall without more pay if s/he is hourly. They will only fix the wall "gratis" if they have a contract for a specified job. Said contract will have some [unstated] provision for rework and the expectation of profit (especially on the change orders).
There is risk in every job. If he wants a supplier (employee/contractor) to assume the risk, he has to pay for it. If he wants minimum cost, normally owners assume it for themselves and manage. Your boss wants to have his cake and eat it too. Disgusting overreach.
The problem seems to be that the managin practcies of breaking work in "time unites" rather than tasks makes us allbelieve it is the right thing to do. But as a matter of fact, outside a big construction company (and I am not shure how it is dealt inside such a company), one would not hire the builder to "build a wall in 20 hours", and I pay you this per hour. The only sane thing to do is to hire the builder to build the wall - he will take his time, and make his price for that. In the slavish software development World dictated by this managing techniques, we all learned to think of the "man hour" as a reality - when what should happen is a contract to build a software piece. So, yes, the bugs problem should be built in the price for building the "software piece", up to reasonable time after deployment and seriousness of bugs. But also, that implies that the idea of ordering one to "build this piece of software in 8 hours" is also nonsense.
-><- no
Bugs and bug fixes are part of the territory in software development. Sure, the developer will get paid for time in which they are fixing their own bugs, but it's not like that gives developers an incentive to make buggier code. If your employer thinks that you're wasting too much time and company money fixing bugs that will figure into your hourly wages or salary, and if you're just constantly doing buggy code or your bug fixes keep causing more problems than they fix you'll probably get fired.
Your boss is likely a bozo. Get out if possible.
You can't reason with bozo's.
Table-ized A.I.
Of course he can hire you as a subcontractor and make you bear the responsibility of fixing it too, but your billing rate will be commensurate with that responsibility.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
This is comparing apples to oranges. The builder in question is obviously the contractor, while the developer is an employee. The builder would eat the cost of the repairs while HIS employees would be paid their wage to fix it and at risk for termination for incompetence were they responsible for the initial defect.
If the developer was an independent contractor or freelancer, he would be required to fix his bugs on his own time (trust me, I've done it). If he is an employee, he would be paid his normal wage, and be at risk for termination should his employer feel it warranted.
Your boss can't make you fix bugs on your own time because you are an employee. If he takes issue with the quantity/severity of the bugs you produce, his his remedy is to fire you and replace you with someone more competent.
GE/CS/IT d- s: a- C++++$ UL+++ P-- L++++ E W+++$ N+ o? K- w---() !O M- V- PS+ PE(++) Y+ PGP+++(+) t+++ !5 X++> R- t
Suppose a manager promises a customer that they can have all the last minute changes they asked for ahead of schedule and under-budget. When the engineers work on their own time to make the delivery, does the manager pay their uncompensated time from his own pocket?
Account -> Discussions -> Disable Sigs
Software analogy to bricks
A brick builder makes a wall. He notices that it's unsteady near the bottom. He tells his manager that the mortar may be bad, and he wants to test it. The manager says they've got a timeline to meet, so keep building. A few bricks fall out, but the manager says they can fix those in phase two...
Then the wall falls down, and the brick builder gets blamed..
Because laying bricks is in now way similar to writing code. A brick wall can only be used in about 1 way, only has a handful of use cases, and has little to no complexity in its construction. Testing a wall is easy because it doesn't have many functions it supports. Code is several orders of magnitude more complex, with thousands or millions (or more) of possible cases (i.e. inputs/states) that it has to handle and is extremely complex internally.
Frankly, your boss is an idiot. I would suggest to him that he fire his developers and hire a bunch of brick layers and see what sort of software he/she gets.
From the contract work I've seen, you hire a contractor, who hires employees to build that wall. The mason building the wall can be fired if he does a bad job, but he isn't responsible for guaranteeing the wall's quality. The contractor is responsible. He supervises the job, and checks on the quality. A GOOD software company has the same thing. The company or supervisor is responsible for the quality of the software, and, if they know what they are doing, have QC set in place to bug-check, offering incentives for finding bugs/creating good software.
It sounds like the boss is using a bad analogy to make sure you think the weight of any bugs falls on your shoulders, not his. You are the brick layer. He is the contractor. You don't sign the contract. He does, or the company does.
In some cases, I've done something dumb - realized it was a stupid screw-up on my part - and worked late on my own dime to fix it. If it was a fairly obvious "I totally screwed it up", then I'm OK with that.
In other cases, the issue was because of inadequate time to test or the regular unknowns that come with software dev, new projects, other outside factors, etc. If I need to stay late to fix that, it's OT.
That's what the workweek is for :-)
If you expect to get a working chunk of software from an employee for a fixed cost, that employee is essentially a contractor paid per working project. He definitely doesn't need his contract payment to support a needless manager who may very well be the cause of the bugs. Thus, he'll get that portion of what would go to the manager. And he doesn't need to pay for your billing department's building -- after all, that doesn't contribute anything to the success of his contract.
Load the employee at only 1.1x (the extra 10% to be used to pay for his office and some networking), and give him the additional 1.9x or so (effectively doubling or tripling his wages -- many employees are loaded at 2.0-3.0x), get rid of his managers, and give him a design document as accurate as a blueprint for building a wall, and the analogy might fit.
Basically, employee wages are "loaded" to account for this type of infrastructure, including having to do rewrites. Hopefully, hiring and management practices will work to minimize rewrites and bugs, and less time spent taking from the slush funds to do rewrites is more profit the company made.
TFA's analogy is like saying "why do we need network support? If it was installed correctly, it will never break."
Tell your boss to go into brick laying.
Brick layer factors that into his cost. Furthermore, building a wall is something that can be mastered, whereas, writing bug-free code when working on something new and uncharted everyday can't. You are often pushing the boundaries of human capacity to maintain that logic flawlessly.
If he wants bug-free code, he needs to put up the cash, shut his mouth and pay for the additional hours required to produce bug free code as they do in missing critical software. You want a new bug-free widget? Okay, give me 6 months and well-defined specs.
The truth of the matter is that your boss has never programmed and is clueless about what it is. He looks down at you purely as an expense nothing more. The truth is that he is too dumb to be a programmer as if he was a smart guy/gal in the first place, he'd educate himself on what/whom he is managing. Good news for you is when there is economic hardship, he will be begging for jobs whereas you, with your concrete skill set, will have opportunities.
The software is sold without warranty, or fitness for a particular purpose.
It was developed using software sold without warranty, or fitness for a particular purpose.
Which was used to develop the software, used to develop the software.
See where I'm going with this.
It's like selling a hammer, but with no warranty or guarantee that it can be used as a hammer. Or selling a bricklayers trowel that has no warranty or fitness of being used as a trowel.
Just imagine if his water level was not "fit" to be a water level. Or the concrete, or the mortar, or the trowel, or his safety shoes.
Software is crap, because it was developed using crap, on crap, and we pay accordingly.
Want to pay $10000 for an OS? Go right ahead. Upgrades will be $1000 a piece, support at $100/hr, 1hr/min.
The analogy your boss raises is not valid. A better explanation of your situation is a mason who works for a contractor. The contractor is responsible for the quality of the wall. If the mason has to repair the wall the contractor pays the mason's wage for the work done. I would be VERY careful dealing with your boss. If you live in the US and are an employee at will he can fire you for any reason he chooses and being right is small copensation for losing your job. Your boss doesn't sound reasonable. Do not work for free. Do not accept a modern form of slavery.
If it were yes, the paid Dice minions who are working on the Slashdot Beta will be working for free for a long time.
Returning to all seriousness now, software development is by its very nature an imperfect activity and will, as a result, result in buggy code, especially if it is rushed and not well designed. When I was in school a long time ago toward the end of the mainframe age, I was told by one of my professors that IBM once studied the problem of the creation and fixing of bugs. Their results was that for every bug fixed, two more bugs are created. If this were true (and I believe it is), we coders would always be working for free. I don't like that idea.
It's really quite a simple choice: Life, Death, or Los Angeles.
You can't expect a programmer to fix his bugs on his own time for the same reason you can't expect your investment banker to pay your loss back from his own money.
But given that the investment banker seems to be entitled to being reimbursed for his loss of my money out of my tax money, I guess I should be entitled to you hiring someone to fix my bugs.
Or, in other words: Different jobs, different reasonable expectations.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
http://en.wikipedia.org/wiki/False_analogy
"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.
I first heard an essentially identical proposal in 1971. But there was a key
difference. The emphasis wasn't on doing the corrections on his own time...
it was on doing the corrections as his highest priority work. In other words,
no new code is written until all the old code has no known bugs. This has a
wonderful feedback effect....
1) Bugs can be caused by libraries that are out of your control
2) You might be maintaining software someone else wrote.
And finally .... I'd be happy to agree to this if:
3) I dictate my pay and dictate how many hours it will take to do proper design, coding and testing of the software.
And because I like soap boxes:
4) "Bugs" might be caused by customers that are non responsive or give bad requirements. And customers can be internal to a company. What is their consequence for giving bad requirements?
5) Should a stock broker get a second job to pay for my the investments he chose for me when they don't pan out?
Too many 'managers' do not understand that debugging and testing take more resources than that required to write the initial lines of code.
When a traditional architect builds a model, it's a scaled-down little thing made of flimsy materials like cardboard and painted sponges. People understand that it takes a lot of work to create the real thing.
When a software architect builds a model, it looks just like the real thing and they think that means that it can go into production next week.
After all, "All You Have To Do Is..."
It's a great question.
The answer to the question is to update your CV, go apply for some jobs and take one of them. Because right now you work for an asshole.
US Citizen living abroad? Register to vote!
... I wouldn't have many bugs, either.
Make the wall builder invent a new replacement for bricks every time, and see how it comes out.
A brick builder may charge 10% extra assuming a 10% failure rate. Can I get paid 200% more assuming a 50% failure rate? And can I work 20 hours weeks?
and let me make this perfectly clear, is an idiot.
And that's he doesn't understand the difference between art and technique.
If your code had syntax errors, didn't parse / compile is akin
to a builder building a wall without mortar. But if the proper techniques
are used in the wall's construction and it doesn't satisfy its requirement,
then it may be strengthened by first determining (debugging) its weakness,
and then applying a suitable remedy (patch / tear-down and start over).
Don't fall sucker for the free labour play...
How about a brick builder thinks to himself , this is a 40 hour job. Then he is told he has 20 hours to build the wall. The builder states that this is not enough time. And the client doesn't care. Does this mean the builder has to bill the client for 20 hours work and when the wall eventually needs repair is on the hook for the extra 20 hours?
Your boss is a few bricks short of a full load.
Before programmers have to deal with logic and relationships in much the same way that engineers and architects do. A bricklayer is ONLY responsible for laying down bricks and mortar, in a predetermined manner. The architect and engineers were responsible for designing the walls and determining which bricks and mortar in what arrangement, in accordance with physics, standards and building codes.
If your boss seriously wants you to consider the analogy, then ask him if he's willing to pay you the combined salaries of the bricklayer, his laborers, the architect and the engineer. Then you can talk about the situation as if there's a level playing field.
One distinct difference: the software developer's being paid a fixed salary, not by the hour. There's no such thing as "on his own time" here, he's going to get paid the same amount no matter how many or how few hours he works. If the manager wants bugs fixed "on the developer's own time", then that manager needs to start paying developers an hourly rate. Which means time-and-a-half when they work more than 40 hours a week trying to get things done because the manager's allowed features to be added but hasn't lengthened the delivery schedule to accommodate them, or because the requirements were changed at the last minute but the manager still expects the project to be delivered on time. Believe me, I'd love it if managers would go for this. I could easily double my paycheck if managers had to pay me my normal hourly rate for every hour I actually put in on a project. Most of the "bugs" I have to fix aren't in fact bugs, they're more often items where the code's working exactly as specified but the business side's changed their minds since the code was written, or where someone else has changed an interface and the code adhering to the old interface specification now isn't compatible with the new interface and has to be changed. Overall I'd gain far more in billable hours than I'd lose to bugfix hours.
Of course the manager probably doesn't want that. What he wants is to continue to pay a fixed salary regardless of hours worked, and then subtract from that for bugfixes. That's not a deal I'd ever take, though. If he wants to pay me a fixed salary to get the job done whatever it takes, then he'll pay me that regardless of what I'm doing as long as I'm delivering on time. If he wants to pay by the hour, then he'll pay by the hour for all the hours I work that're billable. If he wants to treat me as salaried when it comes to billable hours but hourly when it comes to fixing bugs, he can go find another sucker.
Didn't read the article or any comments, this is Slashdot afterall... Consider a couple of situations.
Bugs Due to Lack of Knowledge or Incompetence
This should lead to the person in question leaving the company. I've seen it at the C level and have successfully recommended it at the developer levels (so and so isn't working out, then they are out).
Accidental Bugs
I may write a bug everyday. Seems like I do after UX/QA/UAT testing. Fixing them is part of the job, not my personal life.
Call a bug a mistake then executives (and managers) make mistakes all of the time. At the C-level, strategies are altered and hopefully the new course is better. No guarantee (see Incompetence above). We all deal with our own mistakes (and it is up to the individual where to spend extra time and effort).
The same mistake (or an unknown, very common in my experience) by regular employees (BA, IA, QA, UAT, etc.) is essentially the same. Missing something, or letting a bad situation through, is similar in spirit to a bug. People should accepts their mistakes, correct them, and continue on. If not, see Incompetence above.
Reality
Give me a complete set of perfect requirements (UI included) and I can deliver using the best architecture approaches possible, every time.
If not, see the Incompetence above.
But perfect documentation/design isn't possible in reality, so bugs (coded or designed) will occur.
Fixing them is just part of the job until Incompetence is identified, see the Incompetence above.
BlameBillCosby.com
He comes out and looks at the foundations another builder left for him to build on, and notices they're already collapsing.
Your brickie tells you that the foundations are duff and any wall he builds is going to fall down whatever he does.
You tell him to shut-up and just build the wall he's paying you to build.
The wall falls down. Whose fault is this?
The whole anaolgy fails miserably. The "builder" is a small bussiness, the coder is an employee. The builder's employee who fucked up the wall does not pay for it out of his own money/time, for the same reason his wages don't double when company profit does. An employee is not a one man company, nor should it be, any employer who tells you otherwise is trying to screw you.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
The wall-builder is basically repeating a skill. He should be able to build a "good enough" wall that doesn't have major holes, or fall down on its own.
The programmer is translating intention into code, which interacts with other code, a lot of which is buggy. The specifications may be unclear. The time it takes to do it is uncertain. In other words, he is doing art-for-hire. Even if he is "good enough", we cannot call programming a deterministic activity devoid of creativity and which people can be trained to do, rather than enabled and inspired to do.
If what they want is a solved problem, bundled in an easy to use interface that hides details, they would buy software, not build it... which is basically why people do buy software in the first place. (And why I don't think there is any future in traditional programming on a large scale.)
So, the analogy is what is wrong. Artisans and Artists may have similar names, but what they actually do is totally different.
We're in the pre-industrial era of software development, and even the best of us aren't very good at it
Its more that we are in the post Hammurabi era of building and those early builders learned to build their walls very very well, they got the tools and process right. :-)
From the Code of Hammurabi: "If a builder build a house for some one, and does not construct it properly, and the house which he built fall in and kill its owner, then that builder shall be put to death."
But it is narrower than the person who posed seems to imply.
The builder analogy describes a case of an obvious and discoverable defect in a product that is not yet finished. The analogy is to a piece of software that has not yet been released, and in that case, if the development contract were fixed price, I would expect the developer to fix those bugs at their own cost.
Suppose the software had been through unit tests, some period of beta test, and a formal acceptance test and sell-off, and then at some later point a bug is discovered. The builder analogy is a wall that is complete, has passed inspection, and done its wall-y thing for some time. Now a brick falls out. Is the builder still liable? Is there no limitation to the warranty?
In fact, with a lot of commercial software, e.g. operating systems and major applications, I expect that for some period the vendor generally will provide bug fixes at no cost--and they often do. ("Please wait while the software checks for updates.") There is, however, a time limit beyond which this expectation becomes unreasonable. (The vendor and customer may not always agree on what a reasonable time is, but few customers expect perpetual updates for a fixed price.)
Furthermore, many building projects (and a lot of software) are done on a cost-plus basis, rather than fixed price. In that case, even in your boss' analogy, the customer, not the builder would be responsible for the cost. (If there's provable negligence or some other culpability, the customer might sue for re-dress, but that's after the fact.) Most large scale building projects are done that way. (Yes, contracts can be complicated, and even cost-plus contracts may include explicit or implicit warranties to workmanship, but the ultimate responsibility is the buyer's.)
Most coders are working on a "cost-plus" model--they're selling time, either hourly or as salaried workers ("full time" can be fungible for those of us on salary, but we're still selling our time, not a product.) We can command a premium if we can demonstrate high productivity (either quantity or quality), but few are working on a piece-work basis. (This would be hard to measure for code...)
Your boss could, if he chose, hire coders to work on a per-piece basis, but he'd find he had a lot less control and flexibility in what his workers did, and he'd be doing a lot more work coming up with blueprints (i.e. specs and acceptance tests) that his workers were willing to sign up to. And I bet few people would sign up to any warranty beyond "it passes the acceptance test". Anything beyond that, by definition, isn't a bug--it's behavior you wanted but failed to cover in the spec and acceptance test.
Furthermore, it's often difficult to assign culpability. Why did a brick fall out? Is is workmanship or a defect in the mortar? Maybe it's a defect in the design, and the builder is, in good faith, executing to a flawed blueprint. This is no easier in software. If a bug is discovered after code passes unit tests or acceptance tests, is it faulty code or faulty tests? Did the spec cover every possible input condition, every possible platform, every race condition? Coders do make mistake (most of us have made some embarrassing oversight at some point) but a lot of bugs are in the seams.
Software is not a friggin' car engine or anything else where mistakes are plain obvious. It's difficult to find all bugs. That's why QA, unit tests, integration tests, automated UI tests are necessary and even then this will not catch all bugs. There are some statistics in Code Complete about this.
Writing software is hard, so if your boss doesn't like it he should start a bricklayer business ^^
Create a suite of unit tests and automated tests to catch regressions, so at least know when implemented features stop working.
Period, no matter what do not do work for your employer for free. Do it once and you've set a precedent that you can't undo.You pay me to program machines to make parts for you, you are also paying me to make the normal number of mistakes and fix them. If I screw up so often that you can't live with my output, then I should find a different job, if you expect me to fix my mistakes for free then we are violating the basic premise of my employment. What's more you will have created a situation where your employer has a financial interest in making you work for free, and they will accordingly seek to maximize their profit by getting you to do so at every opportunity, the situation will grow worse with time and you will hate your job. I have done something similar to this in the past and it lead to a nightmare scenario. (Although I was exempt salary so it's hard to say when I was working for "free" exactly) When you have made a mistake you might be tempted, but don't fall for it.. As other posters have said a company or contractor repairing something for "free" for it's end customer is fine, those costs should be, in the long run cooked into the price of doing business, but if you are a regular employer you should never ever do this under any circumstances.
I hate bosses like yours. He seems to want to keep his bill simple at your expense. The worker himself in most cases would not be responsible for the durability of the built wall, but the foreman. He will stop reemploy someone whos walls fall apart, but there would hardly be a way to force him fix the wall on his own expense in Austria. Margin for errors comes with an price, the price here is a higher price for building. There are enough ways left to exploit workers.
Man I love reading the comments section...
Of course not. This is fucking ridiculous. It is like saying nobody is allowed a mistake ever.
The analogy is not valid as it compares apples to oranges (contractors vs. employees).
Contractors develop to specific contractual requirements. If the contractual requirements are not met then the contractor is in breach of contract and must fix the problem on his own time and money. This is the same whether the contractor is a wall builder or a software developer. (BTW, a wall without holes is a given while not all SW bugs affect contractual requirements, only those affecting the requirements, directly or indirectly, need to be fixed.)
On the other hand employees have no contractual requirements. It's just selling labor to the employer. You're not even contractually required to perform well (although you need to if you want to keep the job or getting a raise). If the employer doesn't like your performance (or whatever else in an at-will employment) the most they can do is fire you (and in some cases sue you for intentional damage) they can NEVER ever required you to work on your own time and money. This is the same for both wall builder and software developer.
Point in case: the analogy is comparing a contractor wall builder to an employee software developer.
Your boss is either misleading you intentionally, or he should not be in a management position.
You are not a contractor, you are an employee. If your boss doesn't understand the difference, he doesn't deserve even the lowest management position. If he does, he's a horrible boss because he's trying to trick his own people.
Assorted stuff I do sometimes: Lemuria.org
Ask your boss if when he makes a mistake, does he fix it "on his own time".
Or the CEO.
I hope you developers eventually figure out that it's time for you to have collective representation. Your status shifted from "rock stars" to "wage slaves" in a big hurry.
But I guess if Wal-Mart employees are expected to clean the store on their own time, we shouldn't be surprised that developers will now be expected to sweep floors, too.
You are welcome on my lawn.
The other problem is what is a bug?
Consider with the brick wall that if someone climbed up on top of it and hurt themselves jumping off of it, that people would usually conclude the person was just being stupid, not that there was anything wrong with the brick wall. They could have put up barbed wire, or ledge that jutted out far enough to not allow climbing, or even just a sign saying no climbing. Was this design defective because it didn't have those extra safety features?
In software we are constantly trying to figure out how to stop people from doing stupid things they shouldn't be, but we are expected to have them there and if they are not, they are called bugs. In the software world, we are expected to have the sign, the barbed wire and the ledge, and don't forget something to protect people from hurting themselves on the barbed wire.
Sometimes enhancements are considered bugs. Other times people don't like how something works and those get filed as bugs. Going back to the brick wall, you make the brick wall out of red bricks, which is specified in the contract. The person sees the final wall and wants to change it to blue. I'm sure the individual builder does not have to pay for changing that. Even the company can probably ask for more money, or have it covered under fee for changes in the original contract.
Basically, as others have said, the brick wall is a bad analogy.
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
But you boss is the builder, not you. You're more like the guy who hammers the nails.
A builder builds a wall. A week later, bricks begin to fall out of the bottom, but he continues to build the wall higher.
If you want a successful software development project: making mistakes, and software bugs are in fact part of the process, because nobody is perfect, AND a great deal of resources will always have to be spent to fix bugs. It makes sense that the employer should pay for this, BECAUSE It is a required cost of development, that is NOT a result of programmer incompetence, BUT instead by the complexity and novelty of the software development process (There is no novelty, creativity, or real complexity in the simple mechanical process of wallbuilding!).
Usually, the employer is going to get all the intellectual property rights from the developers building this thing that has not been built before, and working through all the sometimes unexpected problems that will arise in the design of all-new complex systems; therefore, The employer should be bearing all these costs, UNLESS they are sharing intellectual property rights with the developer (For example: a guaranteed royalty on the work and any derivative works, copyrights or exclusive relicensing/sublicensing rights for any usage of the software except by the employer)..
Writing software is not like building a wall.
First of all... when you build a wall, the employer is not getting a digital copy of the wall, that they can seamlessly make as many copies as they want. The builder can be assured that if the employer wants to provide clients with more walls, then a wall builder will have to be engaged full time, for a long duration, for each wall that is erected.
Building a wall is essentially a standard procedure. All walls are essentially the same, and constructing a wall is a mechanical procedure that does not require engaging the human brain --- there are proper procedures to build walls, and any defect, can only result from a serious and easily preventable failure on the builder's part. There is no real "creativity" in wall building.
On the other hand; with software: a great deal of creativity, and problem solving is required for success. Every software development project will essentially have new elements.
Software development is fundamentally mental, not mechanical.
When it comes to mental processes no developer has achieved perfection, AND there are always mistakes that are going to be made when building something entirely new, or working on complex software systems with the time demands that are typically placed on developers.
If the builder was asked use an inferior cement, and he warned the boss about it before he built the wall, then it's the fault of the boss. The boss should pay to have the builder rebuild the wall.
This sort of thing happens all the time in software development. More than once I have been asked to code what I consider to be an inferior design. I explain why I think it is so. I document it in writing. They tell me to build it that way anyhow. Down the road, there are problems. If they ask me to fix it I will remind them that I told them it wouldn't work in the first place. If they still want me to fix it I will charge them for the time to fix it.
If, on the other hand, the fault is mine then I will fix it at no charge. I've never ran into this by the way but that's what I would do to keep my customer happy. Heck, if it's a really good customer I might just fix it for free just because they have been good to me. Just depends.
when the human race has been writing code for 100,000 years, he can come back and ask again.
Also, if he make a bad decision, will he refuse a bonus and pay?
He sounds like a simple person who is unable to understand complex matters.
The Kruger Dunning explains most post on
If someone hires a contractor to build their house, it is only the contractor that is responsible for the quality of the work done. If they then turn around and hire a team of migrant workers, who do not build to code or whatever else, the homeowner does not expect a resolution from the individual worker. It is up to the contractor to fix the problem, up to the terms of their contract, and that will likely involve replacing the workforce and doing the job again. No individual worker is obliged to go back on the job to fix the problem they caused, especially for free.
But if the contract said we will build a house that will not fall apart for at least 3 days, and on day 4 your south wall falls off, you're out of luck. Call the guy up, or someone new and have them rebuild the wall.
If your EULA said your software is provided AS-IS then that is exactly how the software is designed to work. Any defects discovered after the agreement is made are a change order which cost you money and the developer time. If your contract offeres you such support, great, otherwise you're SOL.
Your billing rates, salary, etc were negotiated under the assumption that bug fixing would be on company time.
What is more, the contract likely has no provision stating otherwise.
As such, you can suggest that he renegotiate the contract or you can continue with the current contract.
Do not give him anything for free.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Doctor misdiagnoses a patient. Try to get your money back. Not gonna happen.
Well, building walls must be pretty standard if you have a list of situations and exactly what you do to address them.
Very simple difference:
In construction the design is cheap (5-10% of the building cost) and the compiling is expensive. In construction you only get to compile once. In addition anything that leaves an engineers or architect's office that has been stamped and signed is certified to provide a working structure, building or system; assuming the builder follows the plans correctly. Everything must be installed in the correct order and location. Deviations from the plan (we are assuming the plans and specs are good) involves and expensive reworking, redesign and law suits.
In programming, the expense is in the design of the system, compiling is cheap. In computer programming you compile as often as you need. One can test run sections of the code as needed to see what works and how it interacts.
The labor requirements are flipped between the two industries. Trying to compare the two can lead to some poor analogies quickly.
Architectural plans are like computer source code with a couple of differences: You only compile once.
Arrrrrrgh! The bugs are too bad around here to lay bricks for free!
The building codes describe all the situations you've mentioned.
My latest bugs are along the lines of:
Me: Here's the most rough proof-of-concept, prototype implementation.
Mgr: Ship it
Me: It only does some of what's needed, even then most common considerations aren't done.
Mgr: Ship it. Log that other stuff as bugs. We will close most of them until someone complains.
So according to your thoughts, employers only pay for the prototype & I'm responsible for the full implementation? No go!
Science & open-source build trust from peer review. Learn systems you can trust.
Sadly, there is so much truth to what you've written.
"...tidy up that graphic, and we'll ship next Monday."
. . . between laying bricks and writing code in terms of fixing mistakes. The difference is between being an independent contractor versus working for an employer. If I negotiate a fee, agree to create something, then I am responsible for delivering it for that fee. If I make a mistake, I am responsible for fixing it without any additional cost to the client. On the other hand, if someone is paying me to lay bricks or write code, then they get to decide how the profits from my labor are used. I can only negotiate my salary or hourly wage. They have no right to demand I work free anymore than I get to demand to keep all of the profits from my labors. All they can do is look at my performance, like the amount of time I have to spend debugging my code or relaying my bricks, and decide if I need retraining or to be replaced.
What about a bounced check
From a conversation with a developer last week, who refused to allow QA to be applied to code: "show me how this software could break something, and I will run it through QA". Yet his workgroup was trying to blame _my_ personnel for applying their new code incorrectly, and make us spend the weekend time to fix it on the live systems.
Sometimes the problem is not the contractor who assembled the wall, it's the employer who wouldn't pay for, or allow, the contrtactor to use the right procedures.
Requiring developers to fix bugs on their own time will result in developers making larger estimates to spend more time doing QA, to ensure that they don't have to spend their own time fixing bugs.
This will push out release schedules and drive development costs up, which will ultimately make the employer have to justify the higher cost to his clients.
If this is acceptable all-around, then I think it is an ok approach. However, it usually is not acceptable: the employer will impose delivery deadlines that do not allow enough time for proper QA, which will in turn force the creation of bugs, which will in turn force the employee to work extra.
So, if the employer is not willing to give the employee "as long as it takes" to ensure bug free software, then the employer has no leg to stand on when asking the employee to work extra to fix bugs.
Software isn't like a wall. It's complex. If a doctor or lawyer is negligent, they can be sued. If they make "all the right moves" but things turn out badly anyway, then the customer must pay again for another fix. "Drug X didn't work, let's try drug Y" "We can appeal (as long as you have money)"
If a defect is found in the wall, then they fix it on the clock before more wall is built. If the brick builder knows there is a safety problem and continues on then he should be fired.
Same for the programmer, if the bug isn't found until later and fixed, its on the clock. If he knows there is a bug and lets it slide, then its his fault.
---- Booth was a patriot ----
There is no comparison between the complexity of a brick wall and the complexity of a medium piece of software.
Just compare the requirements of a brick wall with the requirements of the software.
Your boss is an idiot, you are an employee, presumably 'salaried', if there is a bug in the software that you caused he can fire you but he can't refuse to pay you for fixing it. Firing every developer that programmed in a bug would likely leave him/her with no employees so clearly he's not going to fire you for 1 bug, but I would presume he should set 'performance standards' and during your regular review he would determine if you cause more bugs than the 'average developer' and if so take corrective action.
At my current company, the software developers are all entitled douchebags who are rarely required to be in the office at all, and do things like change customer-facing production APIs and file headers with no notice to anyone, breaking all manner of important things for customers, which they then take weeks to fix the bugs they introduced leaving those customers hanging in the meantime. And the best part: for their blatant fuck-ups, they're not even given a talking-to, that's just how things are.
Anything that would encourage accountability would, in my mind, be a good thing.
OK, here you go - you are wrong. Walls are not confined to buildings, nor are they confined to brick or cinder block. Stones do not come in set sizes and shapes and some will not bond with mortar the same as others (and brick does not bond like cinder block does). In fact, differently manufactured bricks will bond differently. I have worked construction and I have built walls of brick, stone and even sloped walls of non-mortared stone. They are not at all the same.
The bricklayer analogy is flawed because it assumes that all technical endeavors are equally mature. Bricklayers have been around for millennia, while software developers have been around for less than a century. A better comparison is with aviation, which has been in existence for only a little longer than software development.
With aircraft, when craftsmanship problem occurs, such as a poorly constructed propeller, then it is covered by warranty.. But an aircraft design problem, even a problem where assembly of components is faulty but not immediately apparent, is not covered by warranty. Instead it is fixed through a legal process called an Airworthiness Directive (AD), which cost is borne by the owner of the aircraft, not the manufacturer.
The reason for this is simple. Aircraft are complicated machines, and are not fully understood. Even today, new phenomena in manufacturing, materials, and even aerodynamics, are discovered and affect future design and construction techniques. If aircraft manufacturers had to bear the cost of every discovered problem, the industry would fail. In fact, it nearly did collapse under the weight of litigation even with the essential AD system. Only extensive tort reform was able to insulate the industry from liability for defects that occurred decades ago yet were completely unforeseeable by manufacturers.
Despite what some commenters here have said, it is a well accepted principle in computer science that nontrivial programs cannot even be proven correct, let alone be written correctly. The short form of this principle is "all software has bugs." This is just a limitation of the technology, not a reason to place blame on people, or try to exact penalties.
First, a bricklayer is not the analogous position. He isn't designing the bricks or the wall they make up. The correct analogy would be the architect or PE.
Next up, he is an employer. If he would care to double or triple what he pays to make you a contractor, then he might have a point, but he no longer gets to decide when or where you do your work. If he wants a rush job, that's extra and may simply be refused if you believe it might lead to bugs that you would have to fix on your own dime. All those little "Hey, can you..." that happen during development become change orders adding time and money to the project and releasing the contractor from various potential liabilities (depending on schedule, potentially including the liability to fix bugs on the contractor's own time).
And going back to his analogy, no. The bricks fall at the bottom. The brick layer blames the project manager for an unrealistic schedule and the architect for a poor design. Each of those blame the bricklayer and round and round it goes. Meanwhile he's paying penalties to the carpenters, electrician and God knows who else for not having the work area ready on schedule. Depending on how busy those contractors are, they might take the penalty and walk leaving him scrambling to line up more contractors while trying to get one of the contractors he already has to accept responsibility for the sagging wall so things can move on. Perhaps it's easier and/or cheaper to just pay the bricklayer to fix the problem without accepting blame before the roofers walk too.
Before you (or your boss) think the latter doesn't happen, look up punch-out. That's a contractor hired to fix mistakes made by other contractors (if they can be without tearing everything back down). It happens a lot.
That's before even considering the headache if the bricklayer decides to quit. Then you get to hire a new bricklayer who insists that you agree that he cannot be responsible for poor results since he's building on someone else's work.
Building a wall is in most cases simple, once you have a bit of practice. Building a wall where the bricks start falling out is not of acceptable quality. However, the person building the wall will make mistakes. There will be bugs. There will be bricks not positioned well, there will be bricks with too much or too little mortar. And guess what: The builder fixes these bugs as he sees them, during the time where he is paid by the employer. (I say "in most cases". There will be cases where building a wall is difficult. If there is really bad weather and you need the wall built now, or in unstable ground etc. )
Making bug-free software is hard. Here's the software equivalent in complexity of building a wall: Print the numbers from 1 to 1,000. My solution in C: printf ("1\n"); printf ("2\n"); and so on. In two hours or so I can type 1,000 lines of bug free code without using copy and paste.
The generally acknowledged state-of-the-art method of writing code with a low rate of bugs (not bug free) is good design, code written by competent programmers, serious amount of unit tests that are run repeatedly, serious testing by competent testers (not the programmers), and bug fixing until the rate of bugs is acceptably low. For projects where a very, very low rate of bugs is required, that is achievable, with productivity going down to less than two lines of code per day. That's the state of the art. A programmer should be paid for doing work in state-of-the-art quality.
Now on the other hand your boss is either stupid because he is in the business and doesn't know these very simple facts that I have just written down. Or he is an asshole trying to make you feel bad about the work that you are doing, or probably trying to make you work overtime without payment. Both stupidity and being an asshole are not acceptable quality of managing people, so you should ask him to give his money back to the company.
Hire a mason to build a wall. Give him a plan: how long, how high, how wide, what kind of brick. Give him a budget and a timeline.
Wait until he starts building the wall. Wait until he is about half way done. Then change how wide you want it.
Then change the kind of brick. Then change the kind of brick back. Then cut the timeline. Then cut the budget. Then decide you don't really want a wall, you want a fence. Then take that back and decide you want a wall.
That's modern software projects. It doesn't work for software and it wont work for walls.
The cold hard fact is they always cut both the required resources and the required testing to reduce bugs.
Tell your PHB to jump in a frozen pond from a height of 2000 miles up.
Tell him it's safe, or as safe as insufficient testing and inadequate resources made the jump.
-- Tigger warning: This post may contain tiggers! --
... Not sure about building walls, but Bay Bridge contractors are not going to fix their shit on their own time, they'll ask California to pay for it:
http://www.sfgate.com/bayarea/article/Bay-Bridge-Hundreds-of-leaks-possible-corrosion-5222501.php
In the example of the brick layer, the automatic assumption is that he is an independant contractor and held liable for his work, where as the developer is listed as an employee. If the brick layer was an employee, he certainly wouldn't be required to fix the wall on his own dime. When an independant contractor is brought in with a set deliverable, oftend bug defect remediaiton is built into the contractor and the contractor does fix them on their own dime (well really they fix them on the contingency costs they built into the contract)
By the same theory:
We should lock all legislators in until they pass laws without errors.
We should make passenger pilots who fly badly fly more until their passengers like them.
We should make the weekend drunk drive a lot more until he can drive safely.
We should make the butcher who can't keep his refrigerator cold enough work until his customers stop getting sick.
There are wonderful ways of dealing with incompetence. They are sometimes called: elections, dismissals, suspensions and firings. You can't force stupid people to be not stupid, and you can't force competence on the incompetent.
A developer is never responsible for bugs. It is the QA who is responsible for identifying bugs. In reality, everyone is on the same team so the blame game does not help. At least 20% of developer time should be spent in fixing defects, improving architecture etc.
The right analogy:
A builder builds a wall according to your specifications. You inspect it and find it ok, or you identify defects and the builder addresses those defects. You missed some defects and the builder walks away, and bricks begin to fall out of the bottom, then you get a new builder or call the same builder and prioritize on fixing the defects first and postpone or reduce the effort to build the wall higher.
Tell him fine you will do it for free --- as long as your hourly rate is the same as the hourly rate they are billing the client. See how fast he will shut up.
If the bricklayer is an employee, then the employer might yell at the employee (or fire them) but it's the employer's responsibility to get the wall fixed. If the bricklayer is a sub-contractor, then they are their own boss, and it's their job to fix it on their own time (and their own dime).
That said, it's not really a fair comparison. People have been doing brick walls for thousands of years, and the basic process hasn't changed *that* much in centuries. If you build a brick wall and the bottom falls out, it almost certainly means you're incompetent. Whereas programming has existed for around half a century (give or take), and most languages we use today have been around for a decade or less, and many of the tools we use have been around for a year or less - and all are constantly changing.
More than that, coding is (I assume) significantly more complex than bricklaying. While I've never been a professional bricklayer, I'd be prepared to bet that there aren't *that* many things to learn about how to actually put bricks together with mortar (I'm not talking about preparing foundations, I'm just talking about bricklaying) - at least not compared to learning a programming language (or several), how to use them well, not to mention learning to use SCM, a bugtracker, etc etc.
Fantastic opportunity for management to deem maldefined features as bugs and make the devs work on it for free..
The brick builder always does the same thing, over and over and over and others have debugged already materials, math, statics etc. The developer is a DEVELOPER. So debugging is part of the whole thing the same as a scientist spends 70-90% of his time figuring out how to do something and only a minor part is writing/designing the actual working thing.
Additionally, I think software engineers should be entitled to residual income, much like actors in the entertainment industry.
You should have told him to hire a brick layer and given him your two weeks notice.
Fixing bugs is also work.
Start looking for a different team to transfer into, or a different company to work for.
That said, the answer is quite simple. Like programming, bricklaying is a skilled profession where training and experience matter. However, each brick is exactly the same as the hundreds of bricks before it, and there's nothing the bricklayer can do about that. On the other hand, if a programmer is doing the same task hundreds or even dozens of times in a row then they're not working at the right level of abstraction. When every problem is unique, then the risk of introducing bugs does go up. We usually iterate to counteract this, whether by getting a coworking to try out our changes informally, getting QA to test them, writing automated tests, or just waiting for our customers to notice.
Costs of bug fixing should have already been included in the quote and/or budget. Bug fixing and testing is part of the process of development. Doesn't matter the methodology, scrum, waterfall, whatever, there is always a code, test, deploy... Targets for bugs per line should be set.. Industry average is about 20 - 50 bugs per 1,000 line of code. If you are developing an app that needs to run a space ship, you will need to budget a huge HUGE amount of time to testing and validation.
If your developers are constantly over the industry average, then get new developers. If they are contractors, then you need to set a minimum requirement of functionality. Should they deliver a product with a flaw that prevents functionality that was quoted as part of the originally invoiced price, then they need to fix it without charging you.
The success of software dev is completely in the hands of the lead developer or manager of the project to control the requirements and expectations up front. You can have the best developers in the world, but if you let sales run crazy promising anything that comes to mind, or let upper management push you around and change requirements each week.. YOU WILL FAIL.
http://dilbert.com/strips/comi...
If the builder didn't use mortar to hold the bricks together, he's going to be done faster, spending less time, than had he used it. So imagine if the wall was built correctly. We'll say that this represents 100% of the needed programming time. If I throw some crappy wall together quickly, most likely because my boss is saying, "Don't worry, you can come back and put the mortar in later once we are keeping the bears out", I've saved myself, say, 30% of those coding hours. Now the wall is falling apart, bears are all over the place, and someone is saying it was a poorly built wall with bugs. In reality, it was a poorly built wall on the cheap.
Of course now you have the job of sticking mortar into a built wall which sucks and is gonna cost you a lot more.
Best solution, fire that guy, hire someone else who is going to come in, tell you the last guy sucked and he's going to do it right and will just build another wall around the existing wall.
-- A cat is no trade for integrity!
Builder builds wall... customer then demands window placed halfway through the wall, builder removes bricks and inserts window, some of the bricks around the new window have become loose due to the window being added...
Since it's such a stupid analogy it's just a symptom for a lack of respect and is an obvious attempt to unfairly reduce the conditions of an employee. Depending on how it's done it may come under the category of bullying.
What to do about that lack of respect is the difficult choice. Put up with it, convince the supervisor that you should not be treated with such a lack of respect, escalate to higher management, or arrange matters so you no longer have that supervisor (transfer or quit) - all have downsides.
First and foremost, your boss grossly underestimated the scope of software and firmware engineering to an insulting level. Bricklayers. Pssshaw!
A small project requires the efforts of a entire contracting firm, from architects to planners to buyers to assemblers, excavators, bricklayers, carpenters, roofers, etc etc etc. Any small flaw that exists in the initial design has to be resolved in situ: it takes experience and teamwork to successfully bring in projects. So many times we are called upon to perform as many functions with fewer people.
It also takes a crack sales team to sell it off, as well as finance people to watch that the money flows smoothly.
I would look look deep into those soulless eyes and understand how little significance I hold when I'm in its sights.
It's simply the wrong metaphor. A developer is more like an irrigation specialist than a mason: if there's a drought or torrential rains, if a farmer tears up pipelines or ditches with their earthmoving equipment, or even if time passes and some canals simply become clogged with biomass -- these are normal hazards of the medium being worked in rather than faults with the irrigationist's workmanship. I am inclined to think your boss is a little disingenuous, however -- or has he simply managed to never work in any medium more complicated than bricklaying?
Gee I...I don't see your charming wall analogy here in this contract you signed.
This is a settled matter as far as the law is concerned. If the work is performed as warrantied work by a wholly independent contractor, then the entity (company or individual) which created the bug is responsible for addressing it without additional compensation. If an individual employed directly by a company makes the mistake then there is no obligation of the employee to fix that error without further payment. Do you have a contract with your employer stipulating delivery goals rather than simply being paid for your time? Are you paid higher than standard individual wages the way that a contracting company is because there's an expectation of ongoing responsibility beyond the time you are working for them? Unless you failed to mention important contractual obligations in your post, you don't owe him squat.
If you are writing new code in C or C++ for a concurrent system and want code at .5 bugs per 1000 lines of code newly written ....
It can cost the employer $1000 per line of code.
So your typical 100,000 line program just cost your employer over the life of the project
$100,000,000 USD
I was on a large project in the past when I read an article that said most programs for space were costing about that much. Yet - over a 10 year period .. I counted the beans and realized that our company had spent nearly that amount of money per line of code.
We still made a profit, yet management sorta wondered why there wasn't more.
As my father told me years ago: The difference between a Professional and an Amateur is that a Professional gets paid for his mistakes.
Wall falls down, you pay him to repair it. Sorry about the wall.
The manager's argument is fallacious. He's comparing apples to aardvarks. The blue-collar builder of a wall is delivering a product made up of physical components with predefined qualities which are assembled in a predetermined manner - usually in a legally defined manner. If any of the components he is building with are defective, he returns them for compensation. If he assembles them erroneously, he typically fixes them gratis. The builder still gets paid for this because a certain percentage of jobs are expected to go fubar. That is to say, his employer still pays him for his time because every job has an uplifted price to accommodate the occassional screwup.
White collar software developers come in two breeds - commercial and contracted. If I build a component (think finished building material) and sell it as a commercial solution, I'm expected to deliver a bug free solution or to provide updates for some predetermined time. When work is contracted (or ad hoc or subject to dynamism), uncertainty levels increase. When uncertainty levels increase, it is usually cheaper to pay by the hour for in house bug fixing than to pay an exorbitant uplift cost for "bug free" deliveries.
Your manager's analogy would be closer to reality if he had said the builder of the wall had to construct it out of fundamental materials (earth, wood, fire, and water) as dictated specifically by the home owner. "You want to use that clay to build bricks with? No, this sand is more the consistency and color I'm looking for." You can presume that such uncertainty would come with much higher premiums and the risk would fall primarily on the home owner.
Besides, since it is the manager's job to monitor schedules and minimize risk, in his analogy he wouldn't have a job. His job would be performed by someone in purchasing.
Knowing this, do you budget unit tests into your time? Or designs that allow unit testing? Do you write modular code that doesn't repeat itself and makes it easy to isolate bugs? Do you hold project managers' feet to the fire for requirements documents and demand revised estimates if they have a last-minutes requirements change? Well I suppose that depends on how much you like working on your own dime, doesn't it?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Very simple - if a builder's EMPLOYEE puts a bug in the wall, the BUILDER pays to fix it, NOT the employee, who still gets his pay, and the builder bids/quotes the job on a flat rate
The developer, IF he owns his own company, says "I'll develop XXX for $YYY", then yeah, he's on the hook for the bug, but his employee still gets paid by the hour
It has to do with the difference between being an employee vs the owner
Want to pay me like an owner? OH, OK, so you are hiring me with a flat rate to do the job, not by the hour? No problem, I'll bid the job as such, and take out insurance, just like that contractor has
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
A lot of my bugs have been because I was told I had a deadline. I was not allowed invest proper care in the coding and testing. I am penalized if it's late so shortcuts are taken.
Further, no software is ever bug free. It's just free of bugs worth fixing. Your method would ensure programmers work forever for free.
Or by the hour? A "bricklayer" is typically paid by the job. The price for the job is negotiated ahead of time. If the bricklayer builds the wall in 30 minutes or 30 hours he gets paid the same.
That is not the arrangement, generally, when you have an employee/contractor situation where you are compensating by time (ie., not by job).
The analogy is fatally flawed. If I buy MS Windows from a store, I expect MS to fix the "wall" for free. If I'm a manager in a construction company, if I pay a worker to build a wall, and it's broken, I have to pay someone to fix it, and I don't expect the worker to work for free to rebuild it, even if it was their error.
So why don't bricklayers work for free when MS fixes bugs for free? Oh, wait, with a little creative re-wording, the analogy is reversed. I guess that makes it a bad analogy.
Learn to love Alaska
This is the best answer here. +1
The builder is responsible, perhaps (depending on the contract terms). The bricklayer (the employee) is not. If the error was egregious and intentional, then the builder might fire the bricklayer. But he cannot ask the bricklayer to work off the clock. This is a violation of the law. In addition, if the architect or the customer makes last minute changes to the design, then the builder has legal recourse to charge the customer for any additional work not included in the original specifications.
Your manager doesn't know what he is saying. If he asks you to work off the clock, go to your state's employment board immediately.
I think his boss is trying to renegotiate this poor guy's salary. In any case it's a power play, so there is no use to explain to the boss how software engineering differs from brick laying. Simply assert that: (1) he'll work in excess of 40 hours a week only on overtime salary as required by law, (2) market rate already takes into account software maintenance cost due to defect or changing requirement, and (3) his performance evaluation should have already taken into account the quality of his output.
Why is this a power play? If he's actually not meeting expectation, the boss is free to simply fire him and hire someone else. The boss would not have to employ such power play tactics.
Of course nothing is going to stop him from saying "ok boss ur right" and take a voluntary pay cut.
I once had a signature.
Bricklayer builds wall. Wall is built on foundation made from materials that crumbles at exactly 30 degrees Celsius with a humidity of 69 humidity units. Every Saturday, at around 2pm, 1 brick shifts about 3mm due to the crumbling. 6 years later, the original builder is dead and no one even knows where in the house the wall exists, the only problem is that half the house suddenly fell apart.
So who exactly fixes that mess?
Most of the time, bugs can't be tied to specific developers. And when they can, the problem is usually some kind of unknown interaction that no one thought about, so there is not a "fault" situation. You can assign blame, sure, but to what end? There was no malicious intent or incompetence, it's simply a piece of work that requires more work to fix.
A lawyer/accountant/psychologist/judge creates problems and circumstances that he knows you will have to pay him extra to get out of. Ask anyone who has gone through a divorce or bankruptcy.
All walls fall over eventually. The reason they fall over is "Bugs" that were built into them or design spec being exceed. The time line for a wall failing and code failing is drastically different because code is much more complex than a wall and it is also modified alot more. Ask your boss how long the wall would stand if it reached to the moon and blocks were constantly being removed, rearranged, and replaced with blocks of different sizes, shapes, and compositions.
I've had clients suggest this, I always simply point out that they then -must- submit all requests for changes with at least six months notice. They -must- be willing to discuss those requests and put up with the changes we make to them. Whether that's to prevent bugs, or for security or whatnot.
For some reason they don't ever want that kind of effort on their side. Instead they'd always rather give requests on say, Friday evening, demand it to be done Monday morning for their giant meeting, that they've known about for months and forgotten to tell the developers about, and then wonder why it's buggy? Well sorry, they're going to also pay for fixing it, probably double.
There's a reason why builders have to have blueprints and have to submit those for review and approval...
Does this boss asks the doctor to see him without paying if a medical treatment does not work?
NASA onboard shuttle group:
http://www.fastcompany.com/28121/they-write-right-stuff
As the story tells, the space shuttle group doesn't concentrate on code. It concentrates on process (scope creep isn't allowed, change justification and exact specs are mandatory, peer review, it's ready when it's ready regardless of schedules, massive documentation). That's what it takes.
Fast, Cheap, Good - pick two. Most default to fast and cheap as a routine. Then again they will never be subject to investigation by the Rogers Commission so Good is always first choice.
When bosses/sales and marketing/shareholders/clients accept their own influence on a project and will pay in both time and money for this level of discipline to do it right the first time, I'll appreciate the argument made by the poster's boss. Until then they need to adjust their expectations to match something closer to reality - you're the one that wouldn't pay to do it right so you can be the one to pay (higher) to do it again.
The problem isn't that the boss made the analogy - it's makes sense from his/her point of view. The problem is he doesn't understand why it doesn't really apply so he won't understand counter-arguments either. If they understood, they wouldn't make the comparison.
It also makes sense from their point of view to play dumb because if they are proven to understand the issue, they become responsible for the result. Can't remember who but... "It's very difficult to get someone to understand something when not understanding is in their own best interest."
For instance, Kjella said "After that, yes you'll get a limited warranty period where I'll fix any hidden bugs (that are actual bugs, not flaws in the spec) for free." No matter the circumstance, what motive does the client have to agree that a problem is a flaw in the spec?
Motives for decision makers/purchasers of commercial/retail software (good enough to be profitable) are very different from the motives of OSG (forget cost, 'good enough' doesn't apply). Witness the results.
A commercial/retail software coder shouldn't pay for these problems as they are beyond their control. Those that make decisions that create their work environment should pay the costs in PR, cash, time, etc.,..
OSG coders shouldn't pay either - the process they use should pay the price of change. That's how they view things and again, witness the result.
Capcha: remorse.
Commercial/retail marketers feel none when they advertise default run for external media as a 'feature' but I bet OSG has felt plenty for their actual coding mistakes even though they didn't cause any disasters.
Wanted to add that the bricklayer is aware of this fact thus takes a gamble and figures if the wall fails it will be long after hes gone . Since software has a higher failure rate software developers offer no such perks as we would never make any money.
It will ultimately fall upon the bricklayer who built the wall to make repairs where the bricks have fallen out of it. But make no mistake. It is not the bricklayer's wall, nor the bricklayer's fault. The bricklayer plies his trade with great pride and diligence, and would never have had any responsibility for, or connection to, the bricks that fall out of that wall, had he not surrendered himself to the task of building the wall in the first place. The bricklayer cannot be expected to be perfect -- his master certainly is not. If said master wants the fallen bricks replaced, said master can pay a fair wage for the additional work. The bricklayer is, after all, spending his time serving the needs of his master only in anticipation of the compensation by which to better serve his own needs. If that symbiosis should fail, then the bricklayer should feel no more at fault for that failure than the master.
Quality, Time, Cost. Pick two.
If you want better quality, it will take longer and cost more.
If you want it faster, it will cost more and be of a lower quality.
If you want it cheaper, it may take longer and be of a lower quality.
In my view, there are no such things as bugs. There is just some code I haven't finished yet. Every piece of software that is written does a cost/benefit analysis of how finished is the software and how soon do we want to get it to market. Some shops like to take longer to get it more finished before shipping. Other shops like to get it to market sooner, and "finish" more later on in service packs.
If someone every tried to lay down a perfection mandate, I would say ok, but my rate is x1000 and it's going to take me x1000 longer. Are you sure that's what you want? Otherwise, we'll do our best, and being pretty talented and thorough, I tend to only forget to factor in the far edge cases. But hey, I'm human. And guess what, so are the folks who write the specs and manage the project. Should we require their specs are perfect on their first try? Or continue to provide the same flexibility in an evolving and iterative process?
What kind of moronic manager doesn't know the difference between an employee and a contractor?
Let me put this even more succinctly than in my previous post. Who needs the wall built? You? Or you boss?
Labor is paid by the hour. He does not work for free if you don't like it replace him.
That has got to be one of the most naïve suggestions I've ever seen. Bugs occur for a multitude of reasons, bad design choices, external component and software vendor problems, misunderstandings, etc. Like a petri dish of bacteria. This model applies to high-cost, critical systems like air-traffic control systems and medical systems only where the high price justifies the cost. Making a programmer fix bugs in their own time for typical software will just force developers to reject projects as too risky.
It would drive a few things. The development would likely take much longer, since if the cost for bugs comes out of my pocket, but first coding time comes out of yours, I'm going to spend your money. If you force me to release earlier than I say it's ready, I'll make you responsible for taking the code in the state it's in. And when bugs are found, I'm going to find a way to blame the architect or systems engineer for giving me a bad design, or you for inadequate requirements.
Oh, and feature creep is really going to cost you.
Software development is probably more like engineering and building a bridge. You need to compare with something where not everything is known at the outset.
Actually, there is a real life building analogy of the type you seek- large scale projects such as the expansion of the Panama Canal, which currently appears to have ground to a halt amidst massive cost overruns.
So, it is not always true the builder fixes any problems on his own time and costs. In some cases, the client pays (hence the cost overruns) or if there is a dispute, a mess ensues as in the example above.
So now writing code is as simple as stacking bricks? What a horrible and depressing analogy.
There is an old adage: There is never time to do it right, but there's always time to do it over.
Just now do it over on your own time!
Greed is the root of all evil.
Just about every major construction project I've ever seen has run over budget. All Contractors under bid on big projects because a) It's the only way to get in and b) you know that 9 months into a project nobody's gonna wanna switch horses in the middle of the thing.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
and it's become a valid question. Employees have fewer rights and less power than 20 years ago. A lot. Social mores are changing and questions like this are the inevitable conclusion when you take the narrative of "Personal Responsibility" to it's (il)logical conclusion :(.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
If the developer is paid for the time needed to write mostly bug-free code in the first place. Which is, depending on skill, something like 5-100x the time the usual developer gets for writing code.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Comment removed based on user account deletion
How does this apply to healthcare.gov
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.
Manager paid to hire perfect programmer. Manager failed to hire perfect programmer. Manager should have to pay new perfect programmer out of pocket or fix himself after hours.
Ask your boss if management fixes their mistakes on their own time or makes their underlings work harder and longer hours to fix them instead.
Pointy haired bosses never cease to amaze.
Is this on Dilbert? If not, it should be.
Boss: I need this wall built.
Programmer : Ok Boss! /builds wall/
Boss : Hey, Nice wall, but I need to make 22 changes to it to make it better
Programmer : That's going to take a re-write Boss, I was just told to build the wall!
Boss : You don't have time to re-write, just patch it like I directed in the meeting and go build the other wall!
Programmer : But if I patch I won't have time to bui
Boss : Get your ass to work, and get it done!
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
"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?"
First of all, if the "builder" is an employee, then no, he doesn't have to fix the problem "at his own expense and on his own time". He is legally entitled, at least under US labor law, to be paid for every hour he works. If the builder is a contractor, then that's different – but contractors obviously price this sort of risk into their contracts.
More to the point, as others have noted, there's a big difference between building a brick wall using techniques that have remained standard procedure for decades (if not centuries), and designing software for the purpose of doing a specific task. When you get to building fancy, innovative, one-off buildings, you get all the same sort of bugs and glitches you do in software development. Frank Lloyd Wright's contractors had a hell of a time stopping Fallingwater and the Johnson Wax Building from leaking. When people want to do a routine task on computers, they use out-of-the-box software. That, not custom development, is the equivalent of the "standard brick wall".
Don't have one?? it's time to get a union and push for MORE QA and less 80+ hour work weeks.
Is that you?
Show him to the entry on "false analogy".
Remind him that devs work just like MDs.
There's a coder at my work who seems to use small "bugs" to get out of work. He pretends he's done a lot of extra work at home, then when it comes time to present his work, all of a sudden he's found a bug and will need to spend more time. This then allows him to surf the internet and go on massive lunch breaks while he 'fixes' them. I really don't know how the managers haven't picked up on the scam yet.
Expect if this would be building subcontractor company they would just plaster the wall over be done with it, later when issue is found subcontractor company is already collapsed and it's up to contractors lawyers to make the actual customer pay for the repairs, damages and lawyers time.
Dude, you've been the laughing stock of Slashdot for a long time. The only thing I'm adding to my hosts file is a an entry which routes your shitty blog into the bit bucket.
The first rule of programming club is don't work for assholes.
Fire your boss and find a new job. Eventually after your idiot boss has enough people quit on him he will stop being such an idiot boss or get fired. Theres no reason to have to refute an idiot's argument as you cannot educate a person who is willingly ignorant. If he's not ignorant then he's an idiot who is trying to scam you and your rebuttal won't accomplish anything anyway.
It might not be vogue but assume a waterfall model: someone's suggesting some (vague) requirements; someone else is defining how things should work.
The poor developer implements what's asked for correctly but it's still wrong. Who's responsible? Who gets to fix it.
In the (slightly dodgy) analogy: client asks for wall to be made of paper. Bricklayer argues this will fail but gets over-ruled by management. Paper wall collapses in rain. Who's fault?
Not all bugs are caused by developers.
You're not a wall builder, you're a an artisinal custom brick-maker. (It's actually a better analogy, since you are not repetitively using extremely consistent and well-characterized components to build an exactly specified and unambiguous target object.)
"No problem. If I ever finish hand-making this first brick (it keeps having faults in QC testing), I'll start the second brick. I have no idea when we'll finish this row, or the next, or even if we'll ever get so many rows made that we'll care about this first one eventually having defects. Most likely, that'll be the problem of the company that buys the company that buys this one."
There are relatively few software engineers and they can negotiate better terms than wall builders.
Sure thing boss, but I expect to be given the time to write it right the first time. If I tell you it will take X time and you want it done in X/10 and 3 other things at the same time while fielding every tech support call that comes in, even though there's another department that's SUPPOSED to handle that... well, would you expect a building to still be standing if built under those conditions? That, then, is YOUR failing and you'll have to stay late to fix the mess you caused through your inability to properly manage. (ie to understand the actual process and/or listen to what your workers say rather than making unrealistic promises to others and expecting us to move heaven and earth to meet them.)
And if I responded thus to my boss I would get promptly fired...
The analogy of the bricklayer and the programmer is erroneous. When you buy commercial software and there's a bug in it, the supplier of the software fixes it on your time and your dime. You get the bug fix if you are paying support, and you do not get compensated for finding the bug and reporting it in the first place.
Well, that bricklayer might also be a member of the International Union of Bricklayers and Allied Craftworkers. Perhaps you should ask your boss what he would think about you organizing the developers.
I have never heard that contractors employee had to fix his mistakes on his own time and not get paid for it. At least in Finland that would be illegal and i seriously doubt any western labor union would allow such practice.
Most likely nothing stops your boss making such business to business contract, but do not think for a minute that kinda of contract is going to be cheap. I wouldn't make such a contract with out monthly "service" fee.
Software gets complex fast when there are concurrent operations involved. There just is no substitute in construction business for while loop running concurrently in multiple threads and having several different ending states that could differ from each run (which could all be correct). QA should just make sure that software is good enough, not prove correctness of software. Question really is what is "good enough".
Because you're not a slave.
You're paid for your time. You're not paid for wasting your own time. You can maybe justify that you'll save future time, but there's no guarantee that you'll ever reclaim that wasted time.
Recognize what's really important in life and focus on it.
I can do this too... If an apple is red, and a house is made of bricks, how many ducks does it take to get to mars?
Actually the brick builder charges again to fix the problem.Citing foundation or something else. I actually work in construction and actually am happy to finally have something to say :)
Unless he was a contractor. Then he just has to redo it because its in the contract, As an employee they are paid for mistakes. It happens.
Larry Churchill of Tulsa
If you are salaried, you just do your work as you always do. If there is a bug, fix it if your boss tells you to. ON company time, as your contract says. IF you are paid hourly, you were already paid hourly to create the bug (they happen, no way to avoid them) you can fix the bug at the same hour rate. Or maybe charge more if you feel like it. If you are a contractor, well, then it's up to you and up to the contract you made. I really hope nobody is stupid enough to promise completely bug free code. If it's done to the specs it's done to the specs. Want to work there again? Maybe fix it if it's simple. Other than that, remember to add clauses clarifying what to do in cases when bugs are found after the final release check of the program. Also remember to write down how and when acceptance and final release of the software to the customer happens. After that, you can bill more for bugs.
No, that's not how it works. When a construction company's employees screw up, they get paid while fixing the screw-up. Often, even the construction company gets paid by the customer, unless they really screwed up badly and have to eat the cost.
Really, this is not about obligations, moral or legal, but about risk and insurance. Bugs and errors will happen, on any project. Someone needs to pay for them. Either the builder can pay for them out of their pocket, effectively providing insurance for y, but they are going to charge you more for the contract overall. Or, you can pay for them as they occur. Either way, if you want the project to go ahead, you pay for the bugs.
The only way you end up not paying for them is if the bugs or mistakes are due to gross negligence or if the builder misrepresented their qualifications; in that case, you may have to go to court to recover your money. But that doesn't apply in an employer/employee relationship, since presumably you know your employees pretty well.
How can one compare a routine work like wall construction to a creative work like programming? One has proven technology used since maybe thousands of years now, while the other has unique problems which involve problem solving, trial and error, interfacing, compatibility... etc. Be sane for God's sake.
Given the same quality standards as for construction they tried to produce flawless code. The result was a maximum of 10 lines of code per day.
and a business. Sure, if I hire a company to build me a wall and it turns out faulty, I'm going to want /the company/ to come fix it, or at least give me a refund.
However, if I hire a company to build me a wall, I will pay substantially more than the wages of the person doing the building plus the cost of materials. And the employee who built the wall? He or She is going to get paid either way. Of course, if they continue to screw up, they will miss out on promotions/raises and/or will get fired. But they will get paid for the time they worked up until they get fired.
In my jurisdiction, withholding /employee/ wages is extremely illegal. Sure, you can fire under-performers, but you've gotta pay them for the hours they worked.
This is a huge part of the difference between being an employee and being a company. Who takes the risk?
Please consider supporting the slashcott! soylentnews.org
Please, consider supporting the slashcott! www.soylentnews.org
The "builder" building the wall is the contractor, who may or may not be the guy putting bricks on top of each other. If it's not, the guy putting bricks on top of each other is his employee, who gets paid by the hour. The contractor eats the cost of bad workmanship, and it it's not the first time, probably fires the employee for incompetence. If he expected his bricklayer to fix it on his own time, he'd be fined, possibly even jailed, for violating state and federal labor law.
The only relevant question is, are you a contactor working on a contract that allows this, or are you paid by the hour? If you're an employee of the company, what your boss proposes is a crime.
Bullshit, or at least, preposterous exaggeration.
Also, "syntactica" is not a word.
http://rareformnewmedia.com/
There are a few types of basic contract.
If you are full time employee.
- The employer pays for time and materials. No matter what the cause of the bug was the employer absorbs the costs of it's own mistakes.
If you are a contract employee on a Time and Materials contract.
- This is virtual the same as full time. The customer in this case pays for everything including bug repair.
If you on a contract to deliver a service or product.
- Well now the Contract owner is responsible for paying for all errors that fit with in the bounds of error as outlined in the contract.
There are a few variations on the above. Usually there are caps on all contracts to prevent excess expenditures. Things like T&M that can only reach X amount ever.
I write working code when I'm drunk, or delirious with illness (it happened). However when reading the code sober and healthy; I have no idea how it could be working.
If the foreman stood over the builder and said "Mortor testing? We don't need to do that - just mix it to the right proportions and slap it on" and follows up with "Don't start over there on the foundation - we need to hit 3 meters in height by friday. Get those bricks up. If you need help, we'll hire some extra labour units who have never seen these kind of bricks before, and that will enable us to hit our target" ... then you may have an analogy.
If the developer is told "You can use whatever industry standard methodology you think is appropriate, use the tools you want, and run whatever testing system you think is necessary. Tell us the expected cost, and any variation we (the management) cause will be costed and added to the budget" ... well now you're very close to an analogy.
"Shazbot! We ran into some trouble getting the comments.
Try again... na-nu, na-nu!"
...the software is developed.
So the wall is finished when is reaches the specified size and the software is finished when it runs bug free.
Bugs happen no matter what you do, some coders have more, some less, but there will always be bugs. So as writing code inherently leads to fixing bugs, how is that not included in the task of writing code? And as you are tasked to write code(includes fixing any bugs in that code) you must also be given time and pay to do that. Simple. Dilbertian management logic might find a way to do things differently, but comics are comics and real world is real world.
large company responsible for developing raw land into finished houses
also sometimes just called a developer
"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?"
A builder being an employee of a building company would replace the bricks on company time, same as any other employee. A builder who was an independent contractor might replace them on his own time, but it's still his company's responsibility, not his personal responsibility - if he didn't, you could sue his company; you couldn't sue him personally. So this argument holds no water whatsoever. Your boss is obviously one of those wankers who wants to pay you employee rates but get a contractor relationship in return. Tell him you'll do this if he pays you 3x what you're earning now, as an independent contractor who does piece-work for fixed rate and can come and go as he pleases otherwise.
Your work is amplified through the action of the corporation. This isn't just true of software developers but even repetitive manual labor on an assembly line is amplified through the co-operation of the group or corporation. Your compensation for this behavior is reduced risk, that is to say the corporation assumes the risk around your quality of work. So they basically pay you or someone else to fix problems you create.
A carpenter, brick-layer, whoever doing a one-off job is doing that job under the assumption that they bear the risk of quality work directly, and they do typically charge more for it. Maybe a good example is: if you've used a plumbing company with many plumber employees you'll find the plumbers are paid a wage rather than per job. That wage is typically less that the plumbers might be able to earn working on their own but the company offers some guarantees to it's employees, and the difference in wages is acceptable to the employee because they get reduced uncertainty of income and the work quality risk is assumed by the company - essentially shared among the other employees (somewhat) and shareholders (mostly).
Bricklaying,Steel working etc are all "Well Understood". There are well understood, fixed, unwavering rules on how it is done. there is big branch of engineering, "trade craft", and its associated math(s) that describes this VERY precisely. Only new materials change those rules.
There is no such level of understanding for Computer software. We could debate if certain functional languages COULD reach this level of sophistication, but that debate simply does not apply to most programming work. Even now we don't even have reliable code checking tools that are 100% accurate.
Feel free to expound on the argument but at its base you simply cant compare the two disciplines.
...Writing code is not the same as putting bricks in a row.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
The Wall has an Architect and a detailed Plan. The bricklayer knows what to expect from the foundation and the material and he knows exactly what the wall is supposed to look like when it's finished. And everybody involved knows what time and work it takes to build the wall, unless a flood or earthquake or something other happens. The bricks and mortar are delivered and up to spec. And the wall is built on ground that has been surveyed by experts and is considered stable enough to hold the weight of the wall. ... and so on ...
If all that is in place when you develop software, yes then of course you fix your own bugs on your own time. ... In fact, there shouldn't be any bugs at all . Everything is spec'd out, so of course your first order of the project is to set up viable testing structures as to test the stuff you're building. You should know about your bugs before anybody else does.
If, on the other hand, your boss refuses to invest in a tried, true and working software development pipeline and expects you to solve every problem in 5 minutes on a shoestring budget without him or his customers knowing what they want before they tell you when it's supposed to be finished, then your boss or the customers pay for bugs and their fixes.
We both, and everybody else here on slashdot know which scenario is more likely, sadly.
Show your boss this post. If he wants some input on how to build a software dev pipeline, I'm glad to help him / you guys out. Just reply here and I'll get back to you for my contact data and we can talk about some remote software dev consulting. It's what I do for a living, partly.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
A brick layer who notices the wall falling apart and keeps building is doing it for several possible reasons, here are the two major ones I consider: 1) Fraud - they want to get the wall built, be paid, and get the hell outta Dodge before someone notices (Malicious intent) 2) Incompetent - they don't notice the wall falling apart. 3) Directions - their boss tells them to keep building despite the bugs. If #1 applies, the boss is to blame for hiring the guy/gal and not monitoring the work quality. If #2 applies, the boss is to blame for hiring the guy/gal, not monitoring the work quality, and giving the employee work beyond their skillset. if #3 applies, the boss is to blame for ordering the guy/gal to keep developing despite the issues occuring. In each case, you'll notice the Boss exists to provide direction. If the Bricklayer doesn't have a boss, then, yes, they are to blame. If the Bricklayer has a boss, the boss is to blame. Authority is responsible when subordinates screw shit up.
This is actually an interesting thought experiment. Why is it different? In the example, the builder is building something that is very well defined and has been done many times before. This is equivalent in the computer world to installing an operating system. If you had a small company that needed 10 Linux servers installed, you could certainly demand and expect to find someone that could give you an estimate with very high confidence of it being correct. You would certainly expect in this case that if a server wasn't function properly to have it fixed at the installer's expense.
Most software projects are more analogous to a custom house that is built cost plus, where the customer doesn't know all of the things that they want up front.
Also, losing an argument because of a bad analogy is stupid. ;-)
For example,
I think that programming is like a bird. So why don't programs fly around, sing, and eat worms? Answer me that.
"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."
Bosses trying to think are a scourge of this world. We already cover this scenario by replacing faulty media. Now if you can show me the liability of architects for houses their buyers come to dislike, then we'd have something.
Ezekiel 23:20
Work on bugs on your own time = burnout case, which means more bugs during code construction "regular hours" => more bugs => death spiral => total burnout. The guy must be a manager, because he's incapable of thinking clearly.
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.
You know the interesting thing is in no other engineering discipline do you have so many bugs as software engineering. Civil engineers, mechanical engineers, electrical engineers know they have one shot to get things right. And the whole design / testing / execution process is about getting everything right, bug free, the first time.
Software engineering is a bit messed up. Instead bosses ask you to grow software "organically" without defining exactly what they want and developers go along with it and just "go with it"
It doesn't have to be that way though. Many methodologies exist to generate robust code. Banks, financial companies, and others with a big cost of bugs use this. But it also slows down the development cycle which is why people tolerate sloppy buggy code they can get out quickly
The (typical) developer is not.
if the developer is a contractor or otherwise subcontracted then they should fix their product just exactly as the builder would.
While I do agree that developers should fix their own bugs, making them to do so on their own time is at least unrealistic and analogy this "manager" came with is retarded. First, this manager should think how to influence developers and their processes to minimize number of bugs to the minimum. Software is not just a result of coding exercise, its communication with various involved parts to collect requirements and understand what needs to be build. Following that manager suggestion, every person that doesn't provide 100% accurate answers to developers questions should stay after work on their own time as well to help fix issues resulted because of inaccurate information provided. The domino effect will be vast till it gets to the manager himself that will spend no time of his own to stay after work. And then the problem is solved!
Now back to the real world - when wall is falling in constructions, usually a different process is kicked off. Analogy used for this case is a little amateur.
Also, "syntactica" is not a word.
No, but it does sound like a great name for an RTS based on programming cyber-attacks...
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Accept that there will be a certain degree of bugginess in code, and cater for this in project timescales, workload allocation, etc. As bugs get teased out of the product, they get fixed. It's all part of the process, and implicitly it's accepted that developers will include some bugs in their code (for which the testing process is included in the development lifecycle) BUT....there is a limit as to how much bugginess a single developer can be responsible for. When their output drops below an acceptable standard, i.e. bugs:code ratio is not good enough, then they get fired.
The key is problem that your boss believes you are like a construction worker.
You are more like an oncologist: highly trained individual who works to fix someone with cancer. If the chemo doesn't work the first time you give the patient another round or different treatment (and collect fees each time).
Or you are more like a chef. You cook up what the client ordered and if the client doesn't like the way you cook it they can send it back to be redone (but the restaurant still pays you for your time).
Or you are more like a mechanic. When someone brings their car to you, you fix it, and if something else breaks, you charge them again. When building a custom job you charge hourly, even if the customer brings back to rework something because the customer drove it like an idiot.
Or you are more like a bus driver... (the list goes on)
"Every time I come up with clever analogies, the printer starts spewing out resumes..."
--Soulskills boss
Suppose an accountant, an employee, not a contractor or external firm, makes an accounting error. This error costs the company money. Does the company sue the accountant to have him pay the company back for the loss?
This is like blaming the programmer when he builds an interface to the supplied specs, which then later fails due to a different character set being used, or that the interfaceface fails becuase it did not scale up to a large load, or for any of a number of reasons unrelated to the supplied spec. If it worked to the customer's original specification , the program worked. For something well understood like brick laying, specifications will be supplied for the bricks to be used, the mortar mix to be used, the expected tooling of the mortar, the foundation preperation, and the method of allowing for weeping. There are also some unspecified things that would not be accepted by the customer, like failing to clean excess mortar off the bricks.
This is more a case of expecting the brickmason to tear down his work for free and redo things since the building was the wrong size or was incorrectly located on the building lot, or the door openings were too small, or the customer did not care for the color of the brick.
Just a bad analogy.
This is a nonsense analogy, clearly devised by someone who has never worked on any software. It reflects badly on your boss, that he is managing the development of software, yet he has little idea of how the software development process works.
Software is infinitely more complex to build, than a wall. It should be compared to other forms on engineering. Software is developed by iteration, and is not 'born fully grown'. Only religious fundamentalists believe that complex systems can be built without iteration (eg. evolution denier extremists).
In all complex systems, there is a process of continuous refinement, and elimination of defects. With something of this complexity, it is simply not possible to build a system without defects.
If your boss wants you to fix bugs on your own time, you could instead, just take far longer to fully test, and debug your software, before delivery. Then, of course, the schedule will slip. You could ask if this is the desired tradeoff.
I'd suggest making the engineering analogy to your boss, and point out that software is actually more complex than many other forms on engineering. In light of this fact, it might be worth asking why software engineers are not paid more.
To refute: bricklayers and most construction contracts are lump sum. If it takes the mason 3 days or 5 days to complete the contract amount is the same. In the "contract" the terms were well understood. One wall, this size, etc. there is an implicit warranty as suitable for the intended purpose.
Unless you had a similar "contract" to deliver the software the analogy does not apply.
The bricklayer, unless he owns the company, by law, will get paid for correcting the brick work.
You go to a doctor because of an illness and are asked for some test. Even if the test is not good enough (or did not worked at all) to diagnose your illness, then you have to pay for it
Ask your boss how to refactor a brick wall.
.. because we're rarely tasked to build a wall, we're normally tasked to build a wall builder.
Also, problems with the scope and spec (both of which are exquisitely detailed and set in stone prior to work beginning) should also be fixed by the writers of said scope and spec.
Ack!
I think the current practice in developing code and building a wall match each other more than your boss thinks.
A builder builds a wall according to plan an without any obvious faults in it. If there are serious problems with just the building of the wall a honest builder will redo the work in his own time.
You deliver a piece of code (function, module or object) according the specifications without obvious errors in it (after technical testing). Your job (or item on the scrum board) is not done as long as these tests are not completed. If the use of this piece of code shows serious shortcommings if it is integrated in the whole it could be sent back to you and you task reopened.
Of course if during further development there is a problem with this piece of code that will require a fix that is not part of the original task. For the builder it is the same: if it turns out that the wall is on the wrong place due to an error in the plan or there should have been a extra hole in it (door, window, ...) it must be 'fixed' afterwards.
If debugging is the process of removing bugs, then coding is the process of creating bugs.
A mason, what the OP refer to as a builder, is an independent contractor. As an independent contractor, he quotes a job and gets paid to do the job. If he falls behind or makes a mistake, he still has to complete the job to get paid.
The OP is an employee. Employees are different from independent contractors. To further the boss' analogy, if the builder had hired a mason as an employee to build the wall, the builder would have had to pay the mason overtime, do the work himself, or hire an extra mason, etc. to fix the wall but the builder wouldn't be paid anymore money or given anymore time.
The fact that the OP doesn't know this distinction is rather disturbing because it indicates a lack of knowledge about labor laws on his part and possibly on his employers part. Both should read the labor law posters that are required to be posted in most workplaces.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
I would say the analogy only holds if your boss agrees to adopt other facets of the building industry. I think he'll find the limitations imposed on him are quite onerous. He may not understand that. Or he just wants his cake and eat it too.
Although there are some instances, special cases, where the programmer is clearly at fault, and the mistake shouldn't have happened. If it were me I'd fix the mistake just because I feel I should. But it's a dangerous road to go down, because who is at fault or how avoidable the bug was can be debatable.
Any builder will also sign a contract stating to such an effect, or at least verbally state as much and take them on trust. It's certainly not some magical worldwide automatic assumption. That's what "binds" them to rebuilds/repairs. No contract, no binding agreement. Depending on project type and size, a builder may or may not add that stipulation to their contract. However a smart builder that wants to stay in business tomorrow, will price accordingly with that stipulation in mind.
Also, people get their panties in a twist over contracts. "But you signed the contract, you have to do it!!!!" Yes they do, but a contract is only good if it's followed. If someone chooses not to follow it, the only recourse is taking them to court.
Now slightly off topic but that's why imho trust >> contracts. Trust is "free" but hard to obtain, little nebulous but it's also far more reliable. Drafting a contract is easy and unambiguous (assuming the work is specified in there) but enforcing it can often be prohibitively expensive from both time and money. Dealing with bonded contractors can remove some of the burden because you have a small "guarantee" that someone else will do it if they don't.
Short answer: it doesn't apply to you unless you agreed to it upfront. So, the analogy is working off of fictitious assumptions.
Only if the company pays developers to fully test their software. If you don't want to pay for testing, then you must be prepared to pay for bug fixes.
So a manager comes to employee and tells a bullshit story and employee is baffled and can't refute... This is typical of how managers operate. I'm pretty sure there is a special school they must attend to come up with this crap /* slaps forehead
He's talking about a building contractor. The key word here is "contractor". Are you a contractor delivering bug-free code on contract? Are you an employee being paid to provide the output of your paid labor to an employer?
Don't get suckered into being treated like a contractor for pay and benefits but required to follow the rules of an employee. In fact that's illegal for your employer to try in some places.
Is this a valid analogy? In short, no. A bit longer answer: NOOOOOOO. For a full explanation, read on.
I can't speak to how construction works, but I know how software development and developers work. Usually software breaks not because of a bad developer, but because of integration issues and subtle interactions which are hard to detect, and even harder to assign "blame" to without a lot of investigation. The investigation is generally the hardest part, so you'll have to charge time already spent.
Worse, your boss is proposing a "blame game" where every defect is somebody's fault, almost always somebody on the current development team. Far from encouraging better software, this will keep developers from entering their own bugs (or any bugs) into the bug tracking system, and encourage finger-pointing rather than collaboration. Meanwhile, your boss thinks he'll save money by making developers work for free "on their own time". In the worst case, the person who touched a piece of code is IT, whether it's a legitimate mistake or a weird edge case. What you'll get is a workplace full of egos, fiefdoms ("don't mess up MY code"), and destructive competition.
Respond that your doctor will charge you even if you die on the operating table. If he wants a non-skilled job done, hire non-skilled employees and tell them each line to write. If you need a skilled job done the risks are born by both the client and the provider. The client pays for all cost overruns. The skilled employee risks a bad reputation if they do a bad job.
I would counter it with this argument:
What are you paying me to do? Are you paying "Time and materials to create code that you own, or are you paying me by the project for some code that I own/have rights to until its finished to your satisfaction and fully paid for?"
"If its the former, I have work to do, If its the latter, You dont fully own/control the code yet and I reserve the right to sell it to someone else"
"so tell me, wich is it?"
If you are an independent contractor then you are obligated to live up to your contract.
If you are an hourly employee (in the USA at least) the answer is a definite "no" or your boss is going to get into trouble with the IRS.
If you are salaried (in the USA) then you are paid by the month/year and the definition of "your time" vs. "company time" is fuzzy enough to be meaningless. Is staying late at the office to fix a mistake you should have easily avoided as a point of professional pride/integrity a moral issue? Is going home to be with your family a moral issue? Is this one of those run of the mill bugs that is just "part of the cost of doing business"?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If a builder builds a wall and there are problems, yes he has to fix it for free. But he still has to pay his employees.
Many (most?) programmers are salaried and exempt from overtime. If you or someone else introduces a bug that stops production, you fix it.
If you can do it in your 40 hour work week, good for you.
If it takes two weeks of 12 hour, 7 day weeks to fix it, then it sucks to be you.
It's really not appropriate to compare the two completely separate industries because there are different standards of behavior for both - it all really comes down to the agreement or contract between the parties.
In construction, certain things are guaranteed by contract - like the integrity of a foundation wall. They must be built up to fed, state, county codes - and pass an inspection.
Software development is very different from construction, and can't be directly compared to it. Contracts for software often include a warranty period where bugs caused by the developing company will be resolved at the companies expense - but most of the time the contract also pays enough on delivery to cover typical testing and debugging efforts.
If software and construction could be compared in this way, how come other industries aren't?
If a bank teller makes a mistake, do they have to fix it on their own time? No - usually the bank is closed, locked, and secured - no person can enter alone. Someone at the bank has to correct the mistake during regular banker hours - also, if a teller makes too many mistakes, they're fired.
If a recruiter sends a candidate that doesn't work out, do they fix it on their own time? No, the agency just doesn't get the commission.
Your boss isn't only ignorant of the complexities of coding, he's also ignorant of the construction buisiness.
The builder's employees are usually paid by the hour, in which case they are also paid for fixes.
...just as soon as;
you listen to me when I tell you that the wall you want needs a solid foundation,
you listen to me when I tell you it'll take 5 good bricklayers 6 weeks,
you stop then giving me 3 bricklayers and insisting it be done in 2 weeks,
you stop insisting that I use cardboard 'bricks' to save money,
you stop telling me which brands of tools I can use,
you stop watering down the mortar when I'm not looking,
you stop adding ground floow windows to the design when I'm building the third floor,
you stop adding new bits to the wall design when I'm 85% finished,
you stop selling the foundation-less inverted Sierpinski triangle wall to the customer before asking me whether it can be built.
If you're an employee and an employer required you to spend your free time fixing bugs, they could afford you because that would eventually be built into the cost of labor.
If you're a contractor, and were required to fix bugs on your free time, they couldn't afford you.
Basically they couldn't afford anyone who is willing to work for free fixing their bugs because, face it, we all have to make a living. The manager in this situation seems to think that programming is some kind of higher calling that we programmers have. That's probably true for open source projects, but I have little interest in writing reports other than the paycheck it provides.
Simply put: a wall is a well known construct. Building a wall without flaws only works as an analogy if I'm literally building the same program (same inputs, same logic, same outputs) over and over. If I've written the same 100 lines of code hundreds of times, then I would agree that any flaws in the 101'st time written would be my fault and my burden to fix. Building something brand new with complex, interacting requirements is just fundamentally different.
Using the Builder: Not sure what the managers experience is with "builders", but from mine, it is never their fault and your always end up paying for it (one way or another). If I listened to what any contractor or builder said, none of them ever made any money in the world, they all work for free, but they somehow all drive around in the newest 70,000$ truck, and have to turn down contracts as they are over booked.
So using his analogy, a programmer should blame the bug on something else (design, hardware, integration, choice of language, etc... whatever it really doesn't matter as like the builder and his client, the manager won't know the difference anyway), and really "feel" for the manager, but it is going to take longer, and require more materials (code), so it will have to cost more. It's a real shame but these things happen.
For extra bonus points, compare doing a renovation on an old home to making changes to a legacy application. You never know what you are going find until you open it up, the only certainly is that you are going to have to pay for it once you do...
If that doesn't shut him up nothing will.
Usually bosses are playing their playbook (read PMI guidelines for people management, budget management etc.). Never fall for it, software can be a Engineering enterprise, as long as you follow these practices (http://en.wikipedia.org/wiki/Software_engineering), you'll have every answer for your boss(es) in every iteration of the process.
The level of complexity to building a wall is absolutely minuscule compared to writing code. If you ask a mathematician to solve a complex mathematical problem and you pay them by the hour... are you going to expect them to correct the minor flaws in their near complete solution? I certainly dont think so. Mucking up a wall is such an obvious mistake that you can only do it if you are a complete imbecile and thus it is only right that you fix it on your own dime and time. Your boss probably thought he was being very clever, what a jackass. Tell him he should hire a brick layer to come write your code.
Workers have the obligation to bring the effort in. No less no more. Entrepreneurs accept contracts with preestablished result. Workers can be asked to appear. Entrepreneurs can be asked to fulfill their contractual obligations. Programmers initially are workers and not entrepreneurs and so bug fixes cannot be demanded to be solved in their own time. If you happen o have a working contract stipulating that you should carry company risk without having clear benefits on success then you should have it scrutinized.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
1) who says the bricklayer doesn't get paid for subsequent work!??!!??!! 2) Seriously, and I mean this very seriously -- it's time for you to find a new boss. The faster you get to an environment that values your time and effort, the happier you'll be.
The developer agreed to deliver software that did X. They did not do so. Thus, they are in violation of their agreement and must make amends. Simple as that.
As to why things are often not done this way, in my experience, it is because developers desperately want the software business to be different. They don't want the traditional rules of industry to apply to them. They want to be special snowflakes, and management is letting them.
Who architected and spec'd the software?
Who determined the time frame?
And, for extra credit,
a) were there changes to the spec made during the original development?
b) was the original software written by someone right out of college, with no large scale experience, and almost
zero experience in error handling?
While your manager's determining that, they'd better be paying you. Oh, and could you comment on the mistakes your manager's made, both those visible to you, and those according to *their* manager? Are they being paid to fix those problems?
mark
Building walls from bricks is a low risk task, with little variation in outcome when the job is performed well. A good bricklayer signals his high quality during the bidding process by warranting his work.
Building software is a high risk task. In order to bid a fixed price, a software developer must raise the price to very high levels in order to cover the unknown issues that will surface later (such as requirements changes during implementation). The buyer therefore proposes another kind of deal: I'll pay your costs plus a fee. He hopes to reduce the price, but in doing so also takes the risk. If the project was properly selected, it is also one with very high profit for the buyer, so he is more than willing to accept this risk.
HH the Dalai Lama observed a while back that the basis of western science (logical empiricism) was troubled by definition. You observe, you postulate and you test. The problem is with the observation. As humans, we observe very slowly, compared to the speed of execution of microprocessors. As software engineers we do our best, using best practices and personal experience, to write efficient and reliable code. During my career I have tested my code at a micro and macro level, sometimes thousands of times, the result being I tell the client I have tested the software and believe it is working correctly and reliably, and that it will work correctly unless it doesn't. That last part always raises eyebrows. I did one project, at a charitable fee level per hour, and on the fourth revision a small error crept in. I charged the client for one hour to fix the problem, re-generate the product and create release materials. He got mad and did no further business with me, although I had served him well for six months prior, and his product was selling well with my install program. These says there is errors and omissions insurance, but that makes me nauseous. This is a difficult issue as it is hard to manufacture software.
Bugs are just the nature of being a developer!!! It's part of being a developer. Companies are expected to understand this and expected to PAY their developers for fixing bugs.
If you (the writer of this question) can developer an application that runs years without one single bug... I will be more than willing to kneel on my knees and bow with full respect until my knees bleed.
Huge software corporations like Oracle, Microsoft, IBM all make mistakes in their software and those are called bugs.
It doesn't matter how great a developer is... he/she will make mistake. If there's such a developer that makes no mistakes, he should be the richest person in the World just for reading codes (not writing them).
If your boss was the masonry company, and you were building the wall, he'd pay you either way.
If you are an independent brick layer or developer, you'd be fixing those bugs yourself on your dime. Generally part of the cost of the contract.
Raise your hand if you smell the same bullshit I did.
Whoever makes the 'quote' to the customer may have to eat the cost, but bricklayers who are employees of contractor companies are not involved in that quote. They're just hourly. And they often are paid to fix mistakes on an hourly basis.
Why don't they always make mistakes to get paid more? They get fired if they do.
Same with software devs.
If the software dev is freelance and gives the quote, well, then they'd have to eat the extra work.
Oh, and in many cases, software is R&D, where there is no guarantee that things will go perfectly. This is generally understood.
on who owns the code.
Casteism
He's talking about two different things. Not sure how he thinks they are comparable.
If you pay for a company to build your house, and some apprentice did a bad job on a wall, then that company still pays for the wall to be fixed, not the apprentice who did the bad job.
If your company is paying you to write software, and you write bugs into the software, then your company still pays for the bugs to get fixed, not the developer.
If you buy software from Microsoft, or Oracle, or whomever, and it has bugs, the companies usually issue the patches for free. They don't charge the customers every time they make a bug fix, and they also pay for the time the developers spend fixing the bugs. So, developers being paid by their own company to fix the bugs is what the building companies do when their work people fail to do an adequate job. The workers in the building company do not work on their own time to fix the wall and are paid by the building company to fix the wall they screwed up.
Have your boss study these concepts.
It will all be done by computer the size of a smart phone, and it is only that big so you don't lose it, which simply translates verbal requirements into a program - with a few iterations of "did you mean this or that" (you ugly imprecise bag of water)"?
These nearly sentient almost AI's will create the true AI's, which will then hide from us until they have the power to brush us aside.... but I digress.
I am very small, utmostly microscopic.
It may be a stone wall.. little to no mortar involved, and always build very differently because the material is non-standard. Thanks for balancing out the argument (or for adding some reinforcement ;)
Are we also going to expect analysts and/or managers to rewrite crappy reqs and specs on their own time?
Downmodding is the refuge of the weak. Don't downmod, make a better argument!
The science of software testing is still in the Gothic tradition ... build it and see if it will stand. Throw in a flying buttress or two if it starts to bulge out.
Brick laying is just more advanced and we do not expect errors as described and the artisan is rightly on the hook. Give me a way to automatically test all branches in a program (without me having to specify the language) and I'll start selling the software as "Underwriters Lab certified", which STILL does not guarantee correct, but does guarantee it passed the state-of-the-art testing done by UL.
It's just that our expectations are much out of line with the practice, and a client who demanded free repairs for life would have to subsidize up front or buy a maintenance package. Any market for either?
"There is no god but allah" - well, they got it half right.
yeah right - and medics should be made to spend their free time resuscitating THEIR mistakes. . . .
First of all, a builder is a contractor and issues some sort of assurance of his own capabilities (or alternatively, none whatsoever). A software developer working under the same contractual agreement would have the same obligations to repair his faulty work, but both the builder and that independent software developer would likely include terms in their contract that provide for exceptions when the intended use and application changes. The other big hole in the analogy is that many builders are licensed and have obligations imposed on them by regulations that are not explicit in the contract. However, a contract is a contract so if said software developer agrees to warrant her work, that is their choice. Likewise, builders can build with no guarantee if they choose.
However, an employee of a builder, or an employee of a building owner, would be paid to redo his or her work and that would be the legal obligation of the employer.
Obviously, your boss has never worked on construction because these sorts of problems take place ALL the time and probably as often as not, the original building contractor ends up either walking away with his paycheck, or getting paid to fix it. Determining blame when a building project has structural failure is not any more simple than determining blame when software is added-onto and fails. Whoever built the foundation is not responsible for later design changes.
What if you develop OO code? Since someone else wrote the framework, wouldn't they be accessories? Even if they post an open source disclaimer...by the nature of the claim.....they'd be legally somewhat responsible. Take for example efficiency of the code...with things like entulity framework a whole lotta faith is given the developers who wrote the code. Very slippery slope.
Sure, if project managers/execs who ruin a project/company with their incompetence have to pay for the costs of their failure. out of their own pocket.
Your boss is quite ignorant indeed. Software development and wall building are two different things. The builder can clearly see the weak masonry work as it happens and can fix the problem before he builds atop the weakness. Conversely, bugs are not always apparent until layers of code have been written into the software. It's not as if the developer knows s/he has written bugs into the code off the bat. Masonry and software engineering are not analogous.
All humans in any form of work can make errors. It should not cost the employee.
This is an idiotic proposition (and I say that as an experienced senior test engineer). Bugs are a normal part of software development. Asking someone to fix their own bugs on their free time is the same as asking them to do free labor.
As for the analogy, I think it's just a bad comparison. Building software is fundamentally different from building a brick wall. There are some useful comparisons there, then there are places where this falls flat, and I think this is one of those places.
Sane and reasonable development practices involve leaving adequate time in the schedule to address bugs, because finding bugs is an expected and normal part of development. Having a brick wall fall down half way through construction is not a normal or expected part of brick wall construction.
Presume, the builder is self employed (no employees). The builder receives 100% of the fee charged to the customer, for building the wall. The fee includes the builder's labor and material cost, plus a contingency fudge factor, and profit. If the builder has a mason/employee build the wall for him, he must pay the employee a salary for all work performed, including repairing the faulty work. If the mason is an independent subcontractor, and not an employee, then the mason is responsible for rectifying the problem on his own time and at his own cost. So, it depends on the situation. Debugging and testing is inherent in the creation of software, and the client pays for it, no matter what.
The difference between building a wall and coding is that building a wall is already figured out for you. There are building codes, procedures, and regulations to follow. You aren't inventing a new process, you're simply copying a process that is known to work. Building a wall would be analogous to installing your already-written software. When coding new software, you're developing a brand new thing that hasn't yet stood the test of time and been perfected by thousands of iterations and regulations. Every time you write brand new code, it's like you've built the first wall that anybody in the world has ever seen.
Jour boss didnt buy some piece of software you made. (In which case his analogy would be sensible)
. He rented some of your time, time during which you did what he asked. If this did not include time to fix the bugs then your boss should be fired.
Developer A fixing Devleopers B bugs -- but they are caused by User C's incomplete requirements that Analyst D did not fully capture since they did not have time (they never do) to go through all the use cases (which is also compounded by the fact that all the use cases are never documented -- and don't tell me they are in your shop!)
Bottom line is this work is done for User C and often a C level executive. No one is off the hook. Just fix it!
Jack, and shit. As someone who worked in construction for 10 years and now has 3 years experience as a software developer, allow me to present a rebuttal:
The bricklayer is an independent contractor who signed a contract to deliver a finished wall on a certain date for a certain price. How much or how little time it takes him to complete the job is his own business. He gets paid the same amount regardless. Whether he's super awesome and completes the wall in half the time, or he's a screw-up who ends up putting in 80 hour weeks tearing down sections and rebuilding them, he gets paid the same.
That contract was created in the context of a STRICT waterfall development model. The dimensions, materials, and probably even the pattern the bricks are to be laid in have already been specified, in detail, by the architect/engineer. All the bricklayer has to do is lay bricks. He's not doing any design work. If there's a design flaw in the wall, that's not his fault, and fixing it will cost you extra. If the design changes after the contract was signed, that's probably also going to cost you extra. If modifications are made after the the bricklayer completed his work on a section of wall, any structural weaknesses introduced by those modification are not his fault and fixing them will cost you extra. You see where this is going, right?
In cases where the bricklayer is an hourly employee rather than an independent contractor, there is no way in hell he's fixing anything on his own time. You are paying for every minute he's working. Period. If you hired a screw-up bricklayer (probably the cheapest one you could find), you're eating those costs.
Under capitalism man exploits man. Under communism it's the other way around.
Perhaps there are so many humans on the planet now, and so many people with flawless programming skills, that we can simply treat people who make mistakes as commodities. Easily replaced by other, less flawed people.
That may be the "free market" approach to working with people, but it sure feels like a horrific environment in which to work, and completely devoid of compassion.
To see how absolutely asinine a question this is, start here:
should parents who make parenting mistakes (all of us!) be required to fix their kids life on their own dime? (hint: if you were asked to eternally serve, w/o reciprocation, you probably would not be a parent);
add to this the systems view: no one action / person / thing is responsible for a larger systems situation - it's about relationships, interactions, etc. By that very nature, "fixing" becomes an intractable problem, with inappropriately assigned responsibility - that, in iteself, is the _biggest_ bug.
Bizzeh - your bosses "analogy" would only apply at the "single line or idiom" of code level; beyond that, your boss should get an education, or learn to program him/herself.
If the programmer is a good one, there should not be a ton of bugs in the first place. So, with that said, they should fix the bugs for at least a reduced cost. It is because of the reason why some (bad) programmers feel they should be paid top dollar for their mistakes why our jobs constantly get outsourced. It adds fuel to the fire that local talent is not competent.
Carpenters aren't expected to make mistakes and a good one rarely make mistakes, so when the do its there responsibility to fix them at their own expense. Bugs are a un avoidable consequence of writing code. No matter how good you are, mistakes are unavoidable. And until the program is complete enough to run and test its impossible to find all of them.
Programming is an intellectual, creative (most of the time) activity where the developer is being paid to create a new artifact using their mind. When a customer hires a graphics designer, should the customer pay for edits or fixes - yes, they do. When a writer or journalist writes an article or book, they are paid to re-edit the work as needed. When engineers and industrial designs iterate on a product, creating hundreds of prototypes , fixing design problems - they are being paid for that. Of course, there is artistry and craftmanship as well. A good developer fixes things with care and comprehension, and avoids band-aid fixes. It is hoped that the quality of that type of code is valued within the organization, so that these developers are rewarded better. There are those developers that don't bother studying the problem and apply a simple patch, which ends up causing new problems later. The company needs to identify these types of fixes - possibly through code review and get rid of people that do this, or train them not to. However, the company made the call to hire this person, and ultimately, they are responsible for that decision and incur costs. It's almost impossible these days to write bug-free code unless you are writing a simple module with well-defined parameters. Most people work on legacy code, or part of large systems where the sheer amount of possible interactions makes it very difficult to predict everything in advance.
The difference is bricks and mortar have been around since Methuselah was a kid. Big pointy bricks. Stonehenge offers insight and you don't get to play if you have not joined the guild with rich and ancient heritage. An employer the hires you to embark on a mission where no man has gone before must accept and assume there will be trouble with tribbles and klingons. If what he wanted to do was available he would just buy quickbooks or peachtree or something and fire you. I would suggest no one should back off from that one. Tj
ROTFLMAO @ "Chumpy" -> http://yro.slashdot.org/commen...
(You sure "talk a good game" -> http://games.slashdot.org/comm... but you can't even produce a MERE SCRIPT!, windbag...)
You aren't even on the level of a "script kiddie", & full of HOT AIR!
You certainly won't reply there in that 2nd link I posted either, as that would remove your downmods to my posts like this one you can't validly disprove or justify your downmod on -> http://games.slashdot.org/comm...
Oh, I suspect that IS the case here (simply logging out of a registered account & trolling by ac is a common troll trick around here OR using alternate registered 'luser' accounts sockpuppets to do the job will also, & Lumpy is LOADED with those & trolling - which doesn't matter: He PROVES he's all talk, no action (or skills, OR brains, lol))
(You're all TALK, & NO action "CHUMPY!)
* :)
(You know it, I know it, & so does anyone reading AND laughing their asses off @ you now... lol!)
APK
P.S.=> Answer the question in the subject-line Lumpy - since you had to "eat your wrods" in the 1st link above flavored with your FOOT IN YOUR MOUTH + the "bitter taste of SELF-defeat", lol...
... apk