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?
...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.
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.
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'
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.
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?
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.
Granting the base premise, like a lot of other situations, it depends. Is this a syntax bug, or a semantic bug? A syntax bug should be caught in testing, unit or validation. A developer should be conscientious enough to avoid those. Semantic bugs are going to be more difficult. Did management or the customer change the spec after the code foundation was laid? If so, that can't be held against the developer.
To use the building analog, did they use an architect to design the building? Did they have engineers inspect the drawings to ensure that it won't fall down? Did they inspect the quality of their materials to ensure that could support their specifications? Or he just ask you to keep piling bricks and was shocked that bricks were falling out at the bottom?
Is code just a bunch of bricks? Bricks are pretty simple, they don't have to do anything but exist. Code is logic, and given some specifications you 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
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.
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
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.
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.
-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
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...
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.
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).
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.
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.
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?
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.
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.
Not construction. A manager that insists to manage a R&D project as a construction project is going to have a bad time.
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.
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.
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..
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.
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.
"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.
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!
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."
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.
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.
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
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.
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.
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.
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.
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.
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! --
Just because software doesn't crash or generate an error doesn't mean it's bug free. I wrote a bug that was exceptionally easy to miss and overlook. It did not cause a crash and it was exceptionally subtle. The bug? Truncating to a cent instead of correct rounding. This was in testing a tool to migrate portfolios to a new trading platform. I didn't notice because we were testing with portfolios worth billions or trillions in the appropriate currency. It was really easy to overlook being off by 1 two places after the decimal point. It wasn't a design bug, it didn't cause any crashes, it was because I made a bad assumption.
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.
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..
You should have told him to hire a brick layer and given him your two weeks notice.
Fixing bugs is also work.
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!
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?
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.
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
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
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.
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.
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?
What kind of moronic manager doesn't know the difference between an employee and a contractor?
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
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.
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?
Yeah, right. We all know you took those tiny fractions of a cent and transferred them to an account that you opened.
You can't spell "oneiromancy" without "roman".
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 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?
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.
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?
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.
large company responsible for developing raw land into finished houses
also sometimes just called a developer
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.
"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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Raise your hand if you smell the same bullshit I did.
No, it was neither a superman movie, nor office space. They'd have just been lost in the ether; likely some clients would have been overcharged, some under. It was a simple case of doing, in python, "int(currency * 100) / 100" versus "round(currency, 2)".
on who owns the code.
Casteism
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.
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.
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.
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.
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.
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