Bugs are not deserving to paid-for

Question

I'm contractor. Both I and company I work in same (not American jurisdiction). I get paid by amount of time entered on company's private gitlab x hourly rate. I do have formal written contract with rate.

There are informally agreed upon minimal amounts so it will be full-time work. No rate changes for overtime/work on holidays was agreed upon even if it could be against law here.

Tasks on gitlab have several categories, one of them being bugs (found by testers) and crashes from Crashlytics. Company decided that it's better not to pay for work on bugs (they just remove those hours from official documents on which payment is calculated). Stated reason was that I make those bugs so it's my problem. They don't even take into account that :some of bugs are in old code (somebody before me just decided that network calls will always end successfully AND will contain requested data), some of bugs are in fact bugs in specific versions in system components, some of bugs.

I don't like this. I also don't like to find other job (even if I take in account regular payment delays here). Work here is interesting for me.

What can I do to prevent this unpaid work except by leaving company?

Answer 1

First of all you don't need to convince them with any argument. You're a freelancer then things are formally regulated by your contract.

This depends on your contract specifics but if you are freelancing it's reasonable to assume that any feature has to be accepted to be considered done. If not then this is the absolute first thing to change.

After it's done they MUST pay for any change, including bugs.

While in progress they MUST pay for any bug caused by incomplete or wrong specifications, changes, and external causes (faulty driver, OS updates...). However this might be hard to determine, see later.

Your own mistakes before acceptance might be in a gray area but your EXISTING contract should clarify this. They can't change contract unilaterally more than you can start charging a different hourly rate.

In my experience not charging bugs is controversial because the root cause is often opinionated then it's usually easier for everyone to count them as part of the development process. Wouldn't use some more time to implement that feature correctly from beginning? How much more? Is it caused by an incomplete or unclear specification? New code crashes because of a bug in old code? Old code crashes because of new code? You definitely don't want to play this game on a daily basis.

If you're working with UI then it's even more obvious: a good and sane approach is iterative (with frequent user testing sessions) and some findings are borderline to be bugs (even if you literally and correctly interpreted specifications). I'm sure you experienced this and you know what I mean (for example I'd tend to consider a bug a text box to enter a path without autocomplete, even if specs didn't explicitly mention this feature).

If you need to have this kind of discussions you hardly will go along well with them and you will waste your time and money, to track down a bug might even take days.

If they don't agree on this then walk away IMMEDIATELY, you may like the job but, unless you're ready to give away a possibly significant part of your salary (or to fight for each single bug), you will be the one always loosing something.

Alternatively, assuming you're doing your best to deliver good quality software:

• If they want to renegotiate the contract (and you're willing to do so) you can change your hourly rate to compensate time that you will spend to fix bugs (now you probably have enough data to extrapolate a number). This will cost more money but it's still easy for them to plan for those costs from the updated hourly rate and previous projects/code development speed.
• You do not deliver a feature until you performed all the tests, with all the tools, a tester would do. Of course you charge this as a developer, not as a tester. They'll see that, usually, it's cheaper to let some bugs to be found by testers. Be careful because the definition of what a bug is must be formally agreed. If you are already using all the tools to reasonably deliver bug-free code (the fact that they found some using an automated tool is suspicious) then this will cost much more money to the company because development/testing/fixing estimation is merged together and less predictable. They absolutely need to be aware of its implications because they're paying a developer to do tester's job, including monkey testing which is always part of it.

In my experience if you pick option 2 then you'll also obviously incorporate option 1 (there will always be bugs and no one works for free) then overall costs are doomed to increase. Whenever possible a trusty, sane, and professional relationship should avoid them both.

One side note: don't fool yourself thinking that you can find all the bugs a tester can find. Software testing is a different expertise, a separate art, which needs time to be mastered and it's not just about unit/integration/regression/stress testing (which you MUST already have in-place). Of course you can learn to be a good tester but it won't happen in one day.

Answer 2

Try changing your working scheme to include more of your own testing before delivering the feature. This will cause the tickets to take longer which they will notice. Once asked about the sudden increase of the delivery time just answer that you are spending more time testing various scenario to be sure you are delivering bug-free code. Previously this process was split into loops of testing and bug fixing but since they want to have feature ready at the first go this loops need to be executed before all is done.

This change should either be ok for them or if they insist you spend the same amount of time making a task as before the change and do not go back to paying for fixing bugs then the only option is to leave.

Another possible change in the workflow is to make better tasks. Make sure you do not start working on the task before you got all data, that includes scenarios of the process flow (if you design something like checkout or notification system for the application), devices to work on (for some UI stuff) and so on. If you got all this and the found bug is not included in the requested scenario then it is not a bug but an extension of the task.

Answer 3

There are 2 arguments you should give your employer:

1. You get paid for time worked, not for topic worked on.
2. If they want high-quality, bug free software, they should pay you for creating high-quality, bug free software.

The first argument is important for you to get straight. You get paid for every hour you invest into this software. If your employer starts not paying for certain hours, they don't value you and your work. They basically tell you that fixing bugs is worth less than creating new code.

If you let them value your time differently for fixing bugs, what's next? Documentation is worthless, so you don't get paid. Unit test are not part of the application, so you don't get paid. We decided to exclude this feature from the release, so you don't get paid for the time you worked on it... Don't allow them to start this spiral. Every hour you work for them is worth the same amount of money.

Tell them diplomaticly that your contract says you get payed per hour, indifferent on what you worked on in that hour. If they don't agree, tell them you will set your priorities on the work you get payed for and that tasks that don't get payed will have the lowest priority or won't get done at all.

The second argument is important for your employer to understand. Paying well for certain tasks is an incentive to do those tasks often, but not paying for a task is an incentive to never do the task. By not paying for bugfixes they basically invite you to create buggy software.

In our modern world full of smartphone apps and decades of improvements in traditional Windows software, having a buggy software is a serious harm to the image and reputation of a company. It should be their goal to decimate as many bugs as possible. They should value fixing bugs at least as much as writing new code.

Answer 4

The company is trying to rip you off.

Imagine that manager who decided he or she doesn't want to pay you for fixing bugs had a QA person whose full time job it is to examine every bit of work that the manager does, every decision the manager makes, and find any bit of work and any decision that is not 100% perfect, and then the manager is asked to fix all these things, without pay.

The reason that people find bugs in your code is not that you are not doing a good job, the reason is that there is a QA team whose job it is to find problems, and that your work is used by thousands or possibly millions of people, who are going to find problems.

Imagine getting a painter and decorator into your home who is painting one room and putting up wallpaper in another room, and you insist on work that is 100% perfect and after the initial job is done, you insist that he fixes all the tiniest faults that you find for free. That painter will laugh at you.

You have the choice of doing lots of work for free that should be paid for, or taking a lot longer to produce code that has many fewer bugs from the start, or giving them the choice to either pay you a much higher hourly rate and you fix bugs for free, or they pay a normal rate including for the time it takes you to fix bugs. Think about what you want, and then tell them your decision.

Answer 5

This answer will be unpopular, but I think it needs to be written.

My suggestion would be the pragmatic one: just avoid fixing bugs. They don't pay you for it, so there is no incentive for you to do it.

If they explicitly assign you to work on a bug, reassign the ticket back to the testers with an excuse like "could not reproduce", "need more information" or "it's by design". Don't elaborate on what you mean with this. You are doing this in your free-time, after all.

If you just can't avoid fixing a bug which needs to be fixed so you can implement something new, do so while you are working on a billable feature and burry the fix in the commit. To avoid getting caught, don't fix the bug where it occurs. Build some nasty workaround in the code you are working with or create an entirely new implementation of that functionality.

Will this lead to a good product developed in a short amount of time? No, it will lead to a buggy mess held together by scotch tape which will take forever to develop. But that's what the company incentivizes you to create with their payment structure.

In the meantime, keep your eyes open for a new job. This company is mismanaging its software development. It has no future.