|
free bug fixes = no-no
I have worked on writing some controls for a company. I wrote a lot of controls for them.
I was paid per-hour for the controls.
The problem is ... after more than 1 year of writing controls, they discovered a few bugs and sent the controls to me for fixing.
I usually consider bug fixing free - so I did the work for free, or, in some cases, almost for free.
Big mistake.
When I told them I don't charge for bug fixes, they started sending more and more bug reports for me to fix. They also tried to pass some non-bug issues as bugs.
So I fixed bugs for almost 2 months for free.
This was also the end of our business relationship.
Fixing bugs for free SUXX.
Duncan
Tuesday, October 7, 2003
Isn't this sort of situation the reason that contracts exist?
John Topley (www.johntopley.com)
Tuesday, October 7, 2003
I am about to discover the very same thing. My problem is more about bug definition and whose responsibility it really is.
Yesterday I wasted an hour or so on some elements which suddenly "disappeared" from a web page. It turned out that these elements were visible for the administrator, but not for regular users (which shall not log in).
The "bug" is a feature on the underlying publish engine: Deleting an article moves it to the recycle bin. All links to that article will still be valid, except that regular users are not allowed to peek into the recycle bin.
I knew this was not a bug, but I couldn't prove it.
Next time I will work more to get an agreement on a bug definition and responsibility: When is it a bug, and when is it my problem.
If it is my fault I should clean up for free, otherwise get paid.
Thomas Eyde
Tuesday, October 7, 2003
The company I work for had a special deal going with a client of ours. Any bugs found and reported within 30 days of them receiving the software were fixed for free, but this was only on fixed price projects. Similarly, the client tried to claim additional functionality (or lack there of) as bugs.
My personal opinion is that bugs are part and parcel of the SDLC, and as such fixes are chargable on contracts that are paid by the hour.
Tough lesson to learn.
sjb
Tuesday, October 7, 2003
Simple and nice! I like it. Is the 30 days a fixed timeframe, or do you use a shorter timeframe for shorter assignments?
A bug: An existing feature which doesn't work as agreed and is my responsibility.
Next challenge: How to manage responsibilites?
Thomas Eyde
Tuesday, October 7, 2003
Thomas, the projects we were doing for this client were generally around the $15K to $40K mark. We did extend the time frame to 45 days for one $60K project.
sjb
Tuesday, October 7, 2003
Question: Do the development enviromnents, compilers and third party tools you use offer you free bug fixes?
They don't give me any free good fixes at all. I just cross my fingers and hope service pack N+1 will fix them.
Daniel
Tuesday, October 7, 2003
Microsoft and Borland give away free service packs to their dev environments.
Jackson
Tuesday, October 7, 2003
"Microsoft and Borland give away free service packs to their dev environments."
Yes, but I don't have the "right" to require them. I'm a Borland user and some of the Borland C++Builder bugs sensibly hurt my productivity (some of them not far from being show stoppers) but just have to wait and hope for better versions to come. Sometimes the update packs are published with the relevant bugs not being even open in their internal database. I discussed it in detail in their newsgroups. Relevant to this thread was the fact that IME it's not very common to have the right to specific bug fixes. You just have the right to a generic service pack which may or may not fix the bugs that annoy you.
Daniel
Tuesday, October 7, 2003
Hmmm. My initial reaction would be that a bug is an instance where the software behaves other than how it was specified to act. If it isn't in the spec, it isn't a bug.
Of course a small shop that doesn't really give you a spec, and you build it via a dialogue with them, well that's more difficult. You should have a spec to work from, and they should give you sign off, but if you don't have people dedicated to building a spec for you, that sometimes becomes a difficult (and for the developer, boring) task.
Specifying in the contract a time period for which you will be available for "support" aso makes sense. It also gives the customer a certain level of confidence in you, that you stand by your products.
My 2 bits.
Mark T A W .com
Tuesday, October 7, 2003
aso = also
other crappy type-o's spelling erros and awkward prhasings = please forgive me
Mark T A W .com
Tuesday, October 7, 2003
This is a bit like charging for the razor and giving the blades away for free instead of the other way round. Congratulations, you know have 'skin in the game'.
Java Pro
Tuesday, October 7, 2003
The counter argument is that it's an important customer satisfaction issue when a customer finds a critical bug (that blocks them doing their work) 3 months after the project is over. Asking them to pay for a fix just makes them more unhappy. And unhappy clients generate more unpaid work. (really!)
I tell customers "In general, our policy is to bill all hours during the development phase of a project (which includes new features and enhancements as well as quality assurance efforts) but once a project is actively in use to comp any time fixing reported bugs."
I find fixing bugs is generally pretty quick. If the customer stays happy, they are likely not to argue about what's a bug and what's a new feature. It's also a good personal incentive to do comprehensive testing while I'm still on the client's bill.
The Voice of Rationality
Tuesday, October 7, 2003
Good lord.
You mean to tell me none of you guys have ever heard of a "warranty"?
Put a limited time warranty in your product (60 days will get you more repeat business than 30). Any bug reports after that cost money to fix.
I strongly recommend talking to an attorney to get the contract laid out.
Philo
Philo
Tuesday, October 7, 2003
When I was a boy I worked as a house painter's assistant. My boss was born in Austria, and learned his trade in the old European tradition.
After a year of fetching, carrying and cleaning, I graduated to some internal painting. Sad to say, the first time I was left alone to paint a section of interior wall, I made a terrible job of it.
My boss returned, looked at the wall, and walked out of the room. He returned in five minutes with a scraper, a bucket and a new can of paint.
He put my day's pay on top of the can and said "If you want to keep working for me, you have to do the job properly. If you get it wrong, you fix it in your own time".
I've never regretted that lesson. ALL my company's work carries an unlimited warranty. If you don't like it, don't pay. If you pay, and you later find that we made a mistake, we will fix it free of charge. No catches, no time limits.
Face it, errors are YOUR mistakes. Why should the client pay for work which you got wrong?
Yes, I admit that there are occasional issues with scope, and the definition of error, but I've found that the place to resolve these is before the job even starts, not after the work has been delivered.
HeWhoMustBeConfused
Tuesday, October 7, 2003
--
Face it, errors are YOUR mistakes. Why should the client pay for work which you got wrong?
--
It's easy to fix some errors. Other errors are more time consuming.
If you do work on an hourly basis and your customer signed off on acceptance testing then the customer should pay for time to fix bugs.
If you did a fixed price bid then it becomes more complex. A 30-60 day warranty as suggested above makes sense. Hopefully your code is good and bugs are minor otherwise you're going to lose money fixing the bugs. At some time you have to be able to "cut and run" - if the client is using your software customizations for several years and still getting free bug fixes I think there is a problem! (problem with either their expectations or with your quality assurance).
NathanJ
Tuesday, October 7, 2003
"Face it, errors are YOUR mistakes. Why should the client pay for work which you got wrong?"
If things were so cut and dry. When painting a wall, it's very obvious the difference between "this wall looks awful" and "I consider it a 'bug' that this wall is white instead of yellow". If customers never tried to pull the latter, even asking for white walls, then I'm sure everybody would fix bugs for free, indefinitely.
Microsoft has a very good policy here. "Call us with your problems, and we charge you money. If we believe that it's really our problem and not yours, you get your money back." I think that's entirely reasonable when dealing with software bugs, regardless of the time frame after delivery.
The important thing here is that YOU get to determine what's a bug, not a "consensus" between you and the customer. As long as you're fair, customers won't feel that you're cheating them at all, and will be glad that you step up and own your issues.
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, October 7, 2003
Confused - let's adjust it a bit.
You paint the room, and it looks good to you. You meet the boss outside, he glances in, and gives you your money.
A year later he calls you up and says "this room you painted? The paint has a chip. Come fix it."
How about if he called you today and asked you to come repaint the room? Would you?
Philo
Philo
Tuesday, October 7, 2003
Philo, you can't compare a physical product that wears down and has usage wear to one that remains in a perfect state indefinitely (software doesn't "wear out" over time).
Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, October 7, 2003
"Face it, errors are YOUR mistakes. Why should the client pay for work which you got wrong?"
I generally charge by the hour, not by the job. It's natural to have bugs in software and to fix them as part of the development cycle. My clients are generally satisifed with the explanation that I charge to fix bugs because I would have had to bill the same amount of time if I had discovered and fixed the bug myself before the software was delivered.
Herbert Sitz
Tuesday, October 7, 2003
"Face it, errors are YOUR mistakes. Why should the client pay for work which you got wrong? "
Because he would never be able to afford the perfect bugfree program.
"software doesn't "wear out" over time"
No, the bits do not change, but the whole context in which it is executing does. While comparing this process to "wear" would not capture the true process, implying that a piece of software is good for eternity would assume a> it is perfect, no flaws will be found over time through extensive usage
b> it operates in a particular very well defined and never changing environment
In my experience the set of bugs uncovered during development and in the initial acceptance testing is far, far from complete, and the dynamics of the processes of which the software is a part change over time, creating a never ending requirements drift. So every piece of software "accumulates" bugs through usage and needs ongoing development.
This by the way is one of the things I find very hard to relay to customers. They always seem to underestimate operations/maintenance costs (if bugetted at all) for custom developments. Yes, we all know the SE 101 graphs that show 70% of software costs is incured after the initial development phase, and yet time after time I see these "project based" software developments that are single shot costings, with no link to a recurring budget item for the operations lifetime.
Just me (Sir to you)
Tuesday, October 7, 2003
"My clients are generally satisifed with the explanation that I charge to fix bugs because I would have had to bill the same amount of time if I had discovered and fixed the bug myself before the software was delivered."
I think you are confused between a bug and an unfinished system. When you are in development there are a lot of things that may not be working or need to be polished up. Those are not bugs.
So if you show your client a beta that does XYZ and they say didn't the spec say we wanted ABC, do you say oops that's a bug and charge them extra?
DJ
Tuesday, October 7, 2003
Brad: "(software doesn't "wear out" over time)"
What about Windows v<2000? ;>
A warranty makes excellent sense, as long as the client doesn't abuse the privilege by pretending misfeatures are bugs. (Which, actually, they are in a philosophical sense, but probably not in the context of the warranty.) In fact, as long as they're a client you want to keep (i.e., not abusing the privilege), even misfeatures are worth correcting, because I at least want clients to be happy, so they'll refer more clients.
Sam Livingston-Gray
Tuesday, October 7, 2003
Plus, to a certain extent, fixing bugs for free gives one a powerful incentive to not make the same mistakes again later. Otherwise you start getting addicted to maintenance and customization revenue, then you look up and a couple of years have gone by without your having developed any new products. ;>
Sam Livingston-Gray
Tuesday, October 7, 2003
Brad
>"software doesn't "wear out" over time"
While this is obviously true for the binary bits, the context that the software is used in does change. The business process can change in a subtle way which causes the software to be used in a slightly different way. Sometimes when this happens reports or events triggered by your software no longer work as expected. Now is this a bug or a change in use? Assuming your software allows the entry of the data have a bad response to the data should be a bug, right?
My point being that even though the binary bits do not wear out, the use of software does change over time.
Billy Boy
Tuesday, October 7, 2003
"My point being that even though the binary bits do not wear out, the use of software does change over time."
Yup, but any misbehavior caused by a context change is not a bug, if your product wasn't designed to run under this new context.
Leonardo Herrera
Tuesday, October 7, 2003
Holy cow. Painting walls for software analogy. Not sold here. And software DOES "wear out" in an anlogical sense ... how ... clients upgrade your libraries and they change paths ... yes they do. And they will even try and make changes in your code (thinking Perl/PHP webdev here) that will sometimes work or might just break that other thing when the planets are in the correct alignment. The best response I read was the guy who said that if it wasn't in the spec it's not a bug. As I usually work from emails and phone calls the spec is ether so I decide myself whether it's a bug or enhancement and I charge based on how much I like the client. The idea that you can provide a warranty and it will work forever is fairy tale fodder (as long as they NEVER change anything on the box you put it on ... once upon a time ...)
Me
Tuesday, October 7, 2003
My "bug" for today was actually a change to their database backend, causing their views to be pulled from a different location, which should have been transparent to us but wasn't. Granted, in the end it could be worked around using configuration options, but I spent half a day "fixing" the problem.
Thankfully the customer has a support contract so it's not relevant to the topic, but I can see the same happening to others. Software does degrade! The environment it's in changes, and it gets affected by those changes. Assuming, of course, that your users are the normal sort, not the kind who are so happy with your software they don't mind running Windows 3.1 forever.
Mikayla
Tuesday, October 7, 2003
"ALL my company's work carries an unlimited warranty"
I don't know about anyone else, but I am not going to be fixing free of charge any bugs in 2038 in any of my past programs that uses a time_t structure. Even if the user has kept everything else exactly the same as the day it was installed.
sjb
Tuesday, October 7, 2003
"While this is obviously true for the binary bits, the context that the software is used in does change. The business process can change in a subtle way which causes the software to be used in a slightly different way. Sometimes when this happens reports or events triggered by your software no longer work as expected. Now is this a bug or a change in use?"
This is precisely why I say that the coder should have the only say as to what is a bug or not. If you are fair about your assessment, then you should have no need to go around seeking blanket rules on the JoS forum. :)
If something is being used in a way in which it was never designed or supported, then its failure is not a bug.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, October 8, 2003
The problem here appears to be how to stand behind your product but not get exploited for doing so.
A bug is (should be, maybe) is something that:
- causes the program to crash (or misbehave in a serious way).
- is technically wrong (e.g. 8 days per week) even if it is not in the spec.
- is behavior that is contrary to what is explicitly in the spec.
One might want to fix the above "for free" (but there should be some time limit).
Anything else should be chargable.
njkayaker
Wednesday, October 8, 2003
In the UK the Sale of Goods Act states that a product should be suitable for the purpose for which it is sold. Most other legislations have similar laws.
If you sell a car you can't claim that the brakes not working when going round a corner is not in the spec. Cars go round corners, and that's one of the times they are most likely to need to brake.
There seem to be loads of people here who expect the customer to pay because the programmer didn't bother to work out under what conditions the program would be used.
Stephen Jones
Wednesday, October 8, 2003
>the programmer didn't bother to work out under what
>conditions the program would be used.
Dude you are killing me. Are you one of use uber programmers? For peons like me in the trenches, even the talk of specs and requirements rarely move beyond talk.
Seriously, are you for real? Do you sell software? I'd like to see what you have for sale and read the warranty that comes with it. Or if you just provide servcies, please post your website so I can read the warranty that applies to your services. Or do you just work for a corp and imagine how things might be out there in the real world?
Me
Wednesday, October 8, 2003
We all know specs changes. If they change before implementation then all is good. If they change after the project has ended, is the delivered product then buggy?
Of course not.
How do we react on changes within the project? We say yes, but only if we get more time and money or something else is taken away.
We all know the motivation behind changes: Increased understanding and/or changing business conditions.
Change will come. No you can't say that braking in corners is not in the spec, but you can say that the car was not meant to take corners in 160 (that's km/h but mph also applies).
Thomas Eyde
Thursday, October 9, 2003
Dear Me,
I'm just an end-user who has to work with some of the crap you guys turn out. When you're told it's an added feature to get the little x on the window of the application to either closed the window or be grayed out, then you start reckoning guys like you are pulling a fast one.
Stephen Jones
Thursday, October 9, 2003
"In the UK the Sale of Goods Act states that a product should be suitable for the purpose for which it is sold"
Stephen, I hardly see how the different behaviour of the 'x' at the top of the window violates the sale of goods act.
This example is a very minor thing, but I know from past experience that users think lots of things are very minor which programmers know are not. A line has to be drawn at some stage as before you know it the user is saying things like, "By the way while your changing the functionality of the 'x' at the top of the window, why don't you add the ability to drag and drop files, that shouldn't take long, oh and it would be better if..... "
Programmers have gone out of their way to make things look easy to the end user, and abstract the user away from the finer details of what is going on under the hood, and as such users seem to think there is a button on the developer IDE that says "Make Widget connect to internet and pull in stock report as per paragraph 13-8-2 of revised spec". This is not even mentioning the fact that testing needs to occur the minute something is changed.
sjb
Thursday, October 9, 2003
Dear sjb,
You know as well as I do that the x at the top right-hand corner of a window is universally accepted as a control for closing that window. If it's not going to work for any reason (such as there being OnClose events which might not take effect when the form is closed that way) then it should be grayed out or disappear altogether, so that users do not press it, find that nothing happens and report the application as hanging. A manufacturer can't sell you a car and then tell you where the handle doesn't open the door because he forgot to put in the screw, and then tell you it is an optional extra.
On the same application we have at least one form where the control that is used to exit the form (a door next to the print button) closes down the whole application instead of the form. Are you telling me that to get this to do the job properly is asking for a new feature?
And surely the user has the right to a minimum of intelligible error messages. What is he supposed to do when he gets the message "%1% triggered an unhandled exception" or "data must be between %0% and %1%" when entering marks from one to fifteen in an examdatabase.
You are right that many users will try and abuse the system and ask for added funtionality by the backdoor, just as some consumers abuse the warrantry system and try and get a hardware upgrade, but the confusion you talk about is at least as much the fault of programmers trying to wriggle out of their obligations by pretending bug fixes are actually extra work. If there was more honesty on their part it would be clear what the user could or could not expect.
Stephen Jones
Friday, October 10, 2003
Stephen, it sounds to me like you have as a couple of problems there. It sounds as though your project wasn't speked out properly in the first place, and I would agree with you that the developers probably aren't doing their job properly if the program is in such a state.
One of the problems I face as a developer, when a client asks me to build a program, and wave their hands in the air and say "... I want it to do XYZ ..." quite often they don't want to pay for someone to write up a full functional spek, they think "... I want it to do XYZ ..." is all that is really needed until the developer comes back with a beta version that does XYZ, but in a way the user never invisaged. People that are not developers (and even some developers) under estimate the value of a thorough spek.
The other problem I have seen is that as a developer I quite often find myself sandwiched between management and the client when the spek hasn't been properly nailed in the beginning, especially if this is a fixed price job.
To me it sounds like your application was put together rather quickly, as if the developers and testers were doing their job properly such a problem would not have been alowed past the QA phase, and if it was not speked out appropriately, the developer should have sought further clarification from the client, and changed the application accordingly before it was shipped, however if you were paying by the hour, then you would have worn that cost of adding the functionality at this point. Fixed price jobs are different, and I feel there needs to be some kind of waranty period, say 30 to 60 days from delivery depending on size of project. However, this again should be taken into the fixed price cost of the project.
sjb
Sunday, October 12, 2003
 Recent Topics
Fog Creek Home
| 
