Why do we charge for bug fixing?
So you’ve researched and selected your mobile app development partners. You’ve scoped the project, reviewed contracts and are raring to go. But something is bugging you, quite literally.
Somewhere in the contract there’s a cost for bug fixing. You ask yourself, why should we pay to fix issues in software that our mobile developers have created in the first place? Why aren’t they delivering faultless code right from the start?
What is a bug?
To answer that question, it’s helpful to define what a bug actually is: “A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. “ — Wikipedia
When is a bug?
Given that a bug is an ‘unexpected result’, the only way to truly define one would be to write down the expected result of every situation. We would require a way of documenting every feature in advance down to the most minute detail. Without this, who’s to say what a bug actually is? Everyone involved may view a feature with a different expectation.
For example, we wouldn’t have advanced knowledge of Chrome releasing updates that would impact credit card transactions on a particular app. We also wouldn’t anticipate a rail travel app needing to include tickets booked with a ferry transfer. Not only is it impossible to define every feature in advance, it contradicts our Agile process to do so.
Where is a bug?
You could say that the mobile app development process is all bug fixing. So much of an app developer’s time is spent breaking a feature or a test and then repairing it. This is an integral part of how development works. Therefore, the point at which you spot an issue determines if it is a ‘bug’ or simply part of the development process. If the issue is spotted before it is sent to the client, it is simply part of the development process? If it is spotted after, it is then a bug?
If we were to offer free bug fixing, we’d need to extensively manually test everything before we sent it to the client so that all the fixing is on our side of the chargeable line. Whilst in theory we could fully test every aspect of the app, the reality is that most of the apps we work on are driven by complex data.
We could never fully understand that data or our client’s businesses, so would never spot 100% of the ‘unexpected results’ anyway. Given this, we only manually QA all our builds against the task descriptions which we believe catches 95% of issues, but to reduce the cost to the client, the final complete testing sits with them.
Keeping costs as low as possible is something that is really important to us. We don’t want to charge our clients for something they can do themselves — testing. Equally, we don’t want to overburden our clients with unnecessary work — written-specification.
We believe that the efficiencies and cost savings created by our Agile approach more than cancel out any small costs that might be associated with final bug-fixing.
To put it simply: “Agile Development is not compatible with free bug fixing.”
“”Agile Development is not compatible with free bug fixing.””
Originally published at https://www.brightec.co.uk.
