Code Warranties and Bug Fixing

sneakyimp

I'm doing a courtship dance with a prospective client. This could be a lot of work for me, but the client is insisting on some guarantees with the software we create. In particular, there seems to be an expectation that "bugs" will be fixed without the client having to pay extra money for it, the idea ostensibly being that quality systems shouldn't have bugs.

The nature of the project is such that I feel this might be reasonable for a short-term demo phase, but the scope and nature long-term "real deal" project makes this idea seem patently ridiculous. Should they go beyond a demo stage to a full-on production environment, the traffic levels and experimental nature of their technology obviously will require some babysitting at the very least and it seems likely that their service offering will necessarily evolve in response to customer needs and growing traffic -- if all goes according to plan.

I'm hoping to gird myself for a discussion of these issues via conference call and am sincerely hoping everyone might chime in about how to manage such expectations on the part of a potentially valuable client. Is there a reasonable cut-and-dry distinction between "bug" and "feature" that makes sense to clients and coders? What mechanisms (e.g., maintenance contracts, etc.) can be used to maintain good fences and thereby a solid understanding? My cohort has suggested "acceptance testing" wherein the client accepts the software, but I'm not so sure that covers it.

Weedpacket

sneakyimp wrote:
the idea ostensibly being that quality systems shouldn't have bugs.

Well they shouldn't. But between manufacturers who don't care, and a market that won't allow the necessary effort to be taken to prevent them, they have become all too acceptable.

That said, you don't see Microsoft charging extra for Windows or Office bug fixes.

traq

you need to have a clearly defined project. I always fix bugs - but "bugs" are things that are actually wrong, not just something you want changed. my software works "as described," not "as imagined."

If the client wants something that you don't think will work, tell them it won't work that way - and help try to find an alternative.

dalecosp

I'd think that certainly "acceptance testing" would have advantages --- it should be time limited, which is part of a warranty ("6 months or 60K hits") 😃 ... but it could also have drawbacks ("we're withholding payment due to failure of the acceptance testing").

The spec has to be frozen like a rock, and the agreement, which should be written, should state that clearly, as traq implies.

dalecosp

And Weedpacket makes good points, too. So, if I'm giving a warranty that gives away the farm (read: "my future" in fixing everything they want for $n months), by golly they're going to need to pay the mortgage up front 😉

sneakyimp

Weedpacket, I appreciate that comment about Microsoft not charging. I think it's important to realize that Microsoft fixes those bugs to preserve its reputation in order to sell you or other people more software in the future. Given that website development is typically a one-off thing, it's a bit of a different thing in my case here. I wonder if proceeding in limited phases with clearly defined and fixed objectives* might be the way to go.

Traq & Dale are entirely correct that the objectives need to be clearly defined and set in stone. Seems that the short-term strategic objective here is to get paid to develop that spec 😉

The long-term strategic objective would be to deliver the site in finite, incremental, and clearly defined phases with exact feature and performance specifications.

As for warranties, I would imagine that in addition to time frames, we might also want to limit our liability by limiting development effort to certain browsers (e.g., "Only latest version browsers, no mobile or iPad") or limiting site performance to certain traffic levels (e.g., up to 10,000 unique visitors per day). Can anyone think of other warranty limitations that might be typical?

And Dale, yes, the idea of extra cost for the warranty is certainly something I considered -- either in the form of monthly maintenance fee or a higher upfront cost estimate based on my best guess of maintenance required.

*The strategy ultimately adopted by armies in WWI when faced with horrifying losses for breakthrough attempts. I wonder if a protracted period of trench warfare lies ahead?

NogDog

I disagree that the spec must be "frozen like a rock." The reality is that all specs have to evolve (at least specs for non-trivial projects). The key is to have something in the contract that allows you to evaluate each such change and re-estimate the cost (which may convince the client in some situations that they really don't need certain changes after all, or they're willing to move some other feature to version 2 in exchange, and so forth).

As far as bug fixing, I would not be adverse to writing something into the contract that once the user has accepted the product for final delivery (and they are responsible for whatever user acceptance testing they want done), for x weeks/months/whatever you will fix "fatal" bugs -- bugs that cause the system to not provide necessary functionality -- for "free" (in actuality you need to pad your estimate a bit to cover that). Once that period is over, you can quote them a rate for to keep you on-call, so to speak, to fix fatal errors. Any feature changes, minor touch-ups, etc. after the product has been accepted can then be quoted separately as they arise.

traq

Nogdog: agreed.

Sneakyimp: making spec development the first phase of the project is essential as well. For big projects, there's no reason that shouldn't be paid work.

Weedpacket

sneakyimp wrote:
Given that website development is typically a one-off thing, it's a bit of a different thing in my case here.

Not really. As you yourself say:

Microsoft fixes those bugs to preserve its reputation in order to sell you or other people more software in the future

If you plan on developing websites for other people in the future, you want to preserve your reputation, yes/no?

NogDog wrote:
bugs that cause the system to not provide necessary functionality

str_replace('necesssary', 'contracted', $quote). You don't want them coming to you after acceptance with a wishlist of new functionality and calling its absence a "bug".

traq wrote:
making spec development the first phase of the project is essential as well. For big projects, there's no reason that shouldn't be paid work.

Just as, if an architect is approached by a potential client for a project, and wants some design studies done, the architect can expect payment for the work. (I'm explicitly not including open tenders, because in those the architect is approaching the client; and I'm deliberately saying "design studies" instead of "blueprints" because it makes for a better analogy with software development. For the architect, actual construction is when any bug-fixing is done.)

cretaceous

it also comes down to a bit of common understanding and respect for each other..

had a recent project all quoted and agreed but right at end of development client sends over some new details
I said that's extra work and will cost..

client went bananas and said but we thought that was included.. so in the end did it for nothing (about 2 days work) to maintain the relationship while also making client know it was done for nothing and they should be grateful
(the spec was well written but this item had been casually mentioned in a meeting and was implied it was a bit of a text variation - it wasn't..)
there will always be bits that fall on edges of the spec

IMO a relationship is what keeps work coming through - rather than a strict cost based formula, but sure, clients all like to try it on..

cretaceous

give 'em an inch, they'll demand a mile next (and in half the time!).

there is that ..
(but in this case that project has been evolving over 7 years and this was a step to next level, so it's paid off over the years!)

sneakyimp

2 days work for a seven year relationship sounds entirely feasible. clients going bananas -- i believe that's what we're all trying to avoid.

As it turns out, this project appears to be going ahead and I expect to be paid hourly. The issue of guarantees was punted on for the time being in the interest of moving forward thanks to my sometimes-suave code pimp.

I think we'll all agree that the point is to deliver what is promised and to avoid misunderstandings. I think we also recognize that reassuring a prospective client is a bit of an art form and that maintaining a healthy relationship occasionally requires diplomacy.

Some very interesting points I've taken from this discussion:
1) High-quality work takes time and time and money constraints often require corners to be cut. It's important to recognize when corners are in fact being cut so as to avoid committing oneself to an untenable arrangement.
2) Good fences make good neighbors and both client and contractor should come to a detailed and thorough understanding of guaranteed performance envelopes, acceptance testing, warranty periods, and functionality to be addressed during a project.
3) Flexibility to expand the project is important (you can make more money!) but it should be made clear before addressing expanded projects that the scope is changing and previous agreements must be modified.

I suppose there are other lessons here but these are pretty good starters. If anyone has any anecodotal experiences to add that might shed some light on the distinction between bugs that must be fixed and 'features' that must be tolerated -- or how to reassure a client with soothing words and suave banter, that might be nice.

cretaceous

I think one of the problems is that non-techys have no idea at all how long something takes and at the back of their mind are concerns that they are being ripped off.

After fixing bugs in complex projects I send a one or two sentence description of why it occurred, (as long as it's not a dumbass mistake of my own) which I hope makes them realise the detail that has to be covered and that it's inevitable that some bugs creep through.

The other trick to demonstrate the inexorable inevitability of logic, which is only rarely possible, is when they say can we have 'x' and you get back and say
"yes of course but by adding feature 'x' you do realise it means we have to handle feature 'b' differently because if you remember you wanted 'b' to be automated blah blah... "
and while ususally the client just goes silent and looks like a trapped insect (or as Laserlight might say in a Singaporean moment "goes blur") - sometimes you can see the cogs flipping and remeshing and you realise they do grasp the complexities

But diplomacy and smooth talk I'm not good at!

Derokorian

Basically I explain everything twice. Quick and concise in techno-babble and what I would call a "dumbed down" explanation.

I had a client come to me once saying my code must me all messed up because the site doesn't always work during peak hours. Meanwhile, the client has refused to get more than the absolute cheapest server from one of the hosts I recommended. I explained that the problem wasn't the code but that the site had become too popular for his minimal shared hosting to accommodate. After lengthy discussion and explanation he upgraded to VPS and as such his site hasn't had any issues (that my logic reported or he reported). The hardest part in that situation was explaining the server load and that I was not responsible for paying upgrade fees....

sneakyimp

cretaceous;10994873 wrote:
I think one of the problems is that non-techys have no idea at all how long something takes and at the back of their mind are concerns that they are being ripped off.

That's totally natural. I get that feeling every time I take my car in to have something fixed. I try to keep that in mind when explaining to someone what a project will entail.