4 ms·
Stop offering bug fixes for free. Software development entails bugs; it's unreasonable to expect that bug fixing will be free of charge. If you're selling pre-p
by duncan_bayne 12y ago
Stop offering bug fixes for free. Software development entails bugs; it's unreasonable to expect that bug fixing will be free of charge. If you're selling pre-packaged software with a warranty that may not be true, but if you're billing by the hour you're crazy not to bill for all your time.
Start tracking bug reports carefully. Log all the details of the report, investigation, and resolution. Make these available to your client where possible.
Also, consider that inadvertent misuse of software may constitute a UX defect :-)
- logn 12y agoIt's not pre-packaged (100% custom). I don't know, I feel like if you build something, and it's defective, that you should fix it free. I would expect the same from a car mechanic. I get that software is a hard thing and bugs are inevitable. I'm curious what other people do.
- odonnellryan 12y agoLong-term contracts. $X a month for bug fixes. If they drop the contract, they're billed by the hour. Recurring revenue and the client is happy: they are now able to budget their costs.
- centizen 12y agoI feel like this is not an applicable comparison in regards to workmanship. However, if this truly is the way you want to operate, then I really see no way around simply accepting the situation the way it is now. I can understand why you feel this way, but I don't think it applies to software as much as it would tangible goods or service.
- notatoad 12y agoit's a nice sentiment, but it's unsustainable and it's setting bad expectations with the client. You should not be guaranteeing bug-free software, because that is impossible. The client should understand that the software will have bugs, and that your ability to continue fixing those bugs is contingent on you having a continuing source of revenue. I'm sure they'd rather pay than have you close up shop and have nobody to fix the bugs. Also, i've noticed in my own work that people are always eager to blame problems on whatever component is the cheapest/easiest to solve. If you charge $50/hr for application support and the guy they contract to do virus scans and run disk defragger costs $40/hr, their first call will always be to him, not you, no matter where the actual problem lies. Somebody at their office has figured out that whenever a user has a problem, it's cheaper to pawn the problem off to you and let you do the triage than it is to triage it themselves before calling you. Even if you don't start charging for bug fixes, you need to start charging for wasted time.
- drewcrawford 12y agoThere are a variety of better deal structures available to you. One is to cap your hours/cost. Just build in 40 hours (or whatever) of bug fixing for the first month into the price. Line item it, so the customer knows what he's getting and what it costs. Often customers will complain about this cost, and say they'd rather pay a la carte. Bingo. But if they don't, you have now set clear expectations about what is being provided. Another is to make bug reports consumable. For reference, Apple has a bug fix consumable called a DTS Incident where you pay in advance to have N bugs investigated. Something you may want to consider if the bugs are all invalid is requiring somebody to pay to file a report, and if it turns out valid you refund their money. This may lead to more disputes though it's unclear if disputes are a problem in your situation. In that case you may want 2 hours of your time no refundable for every report. The third thing is technical, and it works even if you don't have a good contract in place. Become omniscient. Log really detailed, invasive things and phone them home. Every user action, all the user's data, etc. Then when the bug comes in you cross-check against the logs and can verify quickly. "No you pressed the delete button, that's why you don't have any data. Not because a bug in the app destroyed it." Make it clear that you are doing this and make it clear that you will disable it, but disabling it voids the warranty.
- greenyoda 12y ago"Log really detailed, invasive things and phone them home. Every user action, all the user's data, etc." Having all their business data logged doesn't sound like a condition that any reasonable customer should agree to. In some cases, such as healthcare related data covered under HIPAA, it would be outright illegal. Asking for this kind of arrangement tells your customer that you don't understand the importance of confidentiality and security, and also tells them that you think they're so stupid that they don't know the difference between a bug and a user error. If a contractor suggested this condition to me, I'd show them the door immediately. You'd also be taking on a serious risk. Even if it was legal for you to have the data, it could open you to legal liability if through some error of yours the data was compromised, costing the client money. And if you had possession of the data, you might get blamed even if the data leak wasn't your fault. Even if you logged the data on the customer's own machines, bad things might still happen, like a bug in your logging code logging confidential data in plain text when it was supposed to be encrypted. It could then fall into the hands of an employee who wasn't authorized to see it.
- justintocci 12y agoi charge for phone calls, travel, bugs that are my fault, bugs that are not and everything else. Basically, if i can't bill another client for the time then i am occupied and must bill. i do not have contracts or recurring revenue to lean on and it sounds like you don't either. look at it this way, its unethical to your boss to not bill for time. Your boss may be you in this instance but you need to act like it isn't and the answers to these questions will be a lot easier to answer.
- mratzloff 12y agoThat's insanity. Everyone expects bugs. Saying you'll fix bugs for free is saying your time isn't valuable.
- duncan_bayne 12y agoSomething to consider: if you're billing by the hour, your clients aren't paying for a product, they're paying for you. Would you expect a company that hired you for a salary to dock your wages for time spent bug-fixing? Make it entirely clear and transparent what you're working on, including time spent bugfixing, and if they're unhappy they can take their business elsewhere. This of course puts great incentive on you to write high-quality code, because your failings in that area will be visible as bugs to the client.
- solomone 12y agoThis is how I consider it and try to phrase it to my clients. They buy my time. If they waste a lot of it with meetings and false starts, at the end of the day it's their responsibility to use my time wisely. That being said, it's my responsibility to make sure my time is of great value to them and produce quality work.
- Moto7451 12y agoAt work when we've contracted with firms, a lot of times the agreements include a few months of paid maintenance (two or three hours per month at a reasonable rate) to cover this stuff. That way they don't disappear and leave us with bugs nor will they feel shafted by our requests to fix issues. Everyone is happy :).
- rmrfrmrf 12y agoI have a question: if bug fixes shouldn't be free, then why are clients able to take freelancers to court under lost revenue due to "errors and omissions"? I used to think that bugs could/should be billed until I had to deal with a horrible client that threatened litigation under E&O and breach of contract. Going to court would put me into debt, so I really felt screwed into working for free. Super bitter about it and thinking about giving up on self-employment altogether because of that guy.
- duncan_bayne 12y agoMy first ever client did that to me, many years ago. Fun aspects of that engagement included: - I ignored a great big warning sign up-front ("our previous developer abandoned the project, refusing to work with us again") - I offered fixed-price (a horrible mistake for a variety of reasons, including that it was explicitly a 'learning project' for all of us) - I didn't mitigate scope creep ("I know we said we'd hire a designer, but can you style the UI as well?") - when we ran into obvious deadline and quality issues, I should have fixed it by re-evaluating things with the client; instead, I tried to "work harder" - finally, when everything went south and the client refused to pay (and in fact demanded their deposit back!) I didn't take them to court for the money they owed me All in all it was a horrible engagement for everyone involved, but a great learning experience for me at least. I hope the clients (quite reasonable people I think, just as domain-clueless as I was at the time) learned from it too. Don't give up though. I continued contracting, and used those experiences to build a simple set of practices that made future engagements a lot more pleasant and productive for everyone involved. One of these is to be super-explicit up-front about how bugs are tracked, resolved and billed. Something to consider: as a software professional, part of your job is to help your clients learn how to engage software professionals. Many clients are either new to the field, try to bring odd expectations from other fields into it, or have been burned by bad engagements in the past and are 100% in CYA mode. Help them get past that :)
- rmrfrmrf 12y agoWOW. This is word for word exactly what happened to me. The worst part is that I KNEW better than to accept this guy as a client, but I was so excited to get a client and get a deposit check that I convinced myself that I could blast through the project.