Hey, this is Overpass Insights! My name is Eric and I make apps! Now today, let's ask
the question - should you charge your clients for bug fixes?
Alright, so during this pandemic, I'm filming from the flat the whole time
because I'm isolated, so I'm trying to bury it up a little bit by moving the
camera around at different angles. So you can see that I've moved my desk out of
the spare room into the kitchen during the pandemic. I'm isolated with my - with
one of my son, so he's got the bedroom now and I'm sort of moved everything out
here, that's why you can see all that junk in the background I. just wanted to
point that out just in case anybody else points it out. And I you know, I'm in my
kitchen. Anyway, I wanted to talk about a comment that came in last Friday's video
from Josh Adams which was very good from a client's perspective. A lot of
times, we focus on the developers and working for clients, but we always have
to think about the clients too. Because they're the most important part of the
of the equation. They're the ones who you know when you do client work, they're the
ones you're trying to please. You don't just want to do a good job for the
client. You want to be able to continue doing good jobs for the clients and have
ongoing work. So, Josh says, "Should a client have to pay extra for a bug the
developer introduced during a project? I think not. As a client, I get tired of
developers wanting to be paid for every little thing when there is nothing the
client can do about a new bug, and who may be out of money. If you introduce, you
fix." Now, Josh, I try to talk about this. I try to respond a little bit in the
comment but I may not have done a very good job because I totally agree with
you like if a developer introduces a bug into the application yeah definitely
they should fix it even after it goes live even after the warranty period
right they definitely should otherwise they're terrible as a developer now if
you're doing it based on time and material then you know then that might
be something different but if you paid a fixed price for a great job and the app
was done and the app was completed and it's released and everything and it's
out there in the wild and then there's a huge bug appears then yeah definitely
it's the job of the developer to fix it right a lot of times I talk about a
warranty period so when we do projects we have like a 30-day warranty period
saying we'll fix anything after 30 days after it goes out if you want to and we
offer extended warranty period if they do want something else just in case
something goes out but there are many times in fact nine times out of 10
there's a bug that's been found like you know three four or five months after if
we go live then yeah I'll fix it right as a professional yeah you have to go in
there and fix it and you won't you don't want some some rubbish out there right
you can't just say oh the warranty periods over you know we got to do that
stuff right now the reason we have a warranty period is because we can't
support the app forever right this is this has happened many times in the past
first of all i OS 13 when that was introduced a lot of things stopped
working right and even though we developed the app during the iOS 11
phase like if I oh s 13 wasn't even a thing when apps went from 32 bits to
know and it would whether started enforcing you know 32-bit applications
then yeah we had to go through and make a lot of changes there but that was not
you know we couldn't go through and change everybody's applications so those
kind of things sometimes you get the bugs that are just yeah definitely you
introduced it into the thing other times is environmental like a new Android
phone comes out or a new our new platform a really good example of this
another good example of this is Android Oh starting with Android oh and push
notifications push notifications on Android needed to have a channel
associated with them which before they didn't write it was kind of a new
requirement so a lot of the push notifications just stopped working on
later phones and that was something it wasn't necessarily a bug it was an
environmental change and that was kind of thing where we had to yeah I
definitely had to charge for it because it was you know we can't just keep going
through like if we go to 128-bit programming or whatever whatever ten
years from now we can't just continue to support an application forever but yeah
definitely I totally agree with you and any any developer out there who is not
proud you know proud of their work in some kits you know it's some way in
order to do that then yeah they they you know dump them get rid of them you know
drop them and yet one I think there's so many developers out there who are very
very good at what they do that you know they would they would be disgusted by
somebody who put something out there with a bug in it and then when you ask
them to fix it you say hey look this is obviously bug you know it crashes all
the time it's nothing expected behavior if they don't fix it or you know they
aren't investigating then you know they're not they're not
worth anything right this is my opinion I and it's difficult because you look at
the two different sides of it like a lot of times developers we could have we'd
have clients to say you know this is a bug but really it's not it's like that's
the expected behavior right that's what what's in the specification that's what
we specified all the way along and they'll say no no because it should do
this or whatever and they'll call that a bug and that sometimes that that's a
very sometimes would be very fine line but sometimes it's clear like if you
click on something it doesn't do what it's supposed to do if it crashes if you
know if it's you suppose come from one screen to another and it doesn't that's
a clear bug right and if your developers don't fix it then then yeah I think I
think that's terrible like there's there's bugs that come from
the code and then there's bugs that come from the environment and you know the
bugs come with the code and yeah I definitely think they should fix it but
as a policy the warranty period should be there I think anybody should be able
to do to put that in theirs and then you know like I said nine times out of ten
you just will fix it because it's you know okay well first of all because it's
embarrassing and because you know we want when what the clients come back. So,
thanks very much, Josh. I just I wanted to point that out because it's a really
good point. And again, a lot of times, I'm working with software development
companies, I'm working with clients and I'm squeezed in the middle where the
developers will say, "oh we need money to fix that bug," and the clients saying, "I'm
not paying for that." And sometimes, you know, I'm in this situation where I
either have to pay for them to fix the bug myself because the developers
but they ain't using those developers anymore. They can go take a hike and
we're not doing any further projects with them. And that usually the
thread that will make them change their mind on that. Oh, you know, so a lot
of times I'm the one squeezed in the middle and I totally - I totally know what
you're talking about. So, the rest of you, guys, out there - those
of you guys who were clients and those guys who are software developers, what do
you think about this? If your client comes back to you with a bug that wasn't
picked up during developmen, wasn't picked up during testing, and you've gone
live. And let's say, you've been - you've been live for six months, would you fix
it? Or does it depend on this a very little bug or what? So anyway,
I hope you guys are having a good day! I hope you're staying healthy. I hope
you're staying safe. And that's it for today. Talk to you again tomorrow.