Fixing bugs AFTER end of contract???

[Steelman]

There is a clause in the contract which is saying that I agree to fix any 'defective services' post contract end at my own cost, as long as I am notified within 4 wks of the contract end.

Anyone else come across this?

This wasn't an issue when I signed at the start, but since being on the project, it is more pertinent now we are nearing project go live & I can understand business behaviour. From the beginning the business users have deemed the majority of system changes as 'critical' and 'bugs' when they are rarely critical (i.e. total fail), and are usually additional requirements rather than bugs. Unfort these users seem to hold sway and my real fear is that post end, they will have a list of things they percieve (rightly or wrongly) as bugs, and therefore demand I fix them. Apart from anything, there are a few devs on this so it may not even be my issue/smthing may have changed post delivery. But the intersting phrase is 'services' and not 'issues' - services seems to imply something quite generic which could be anything depending on how you look at it.

I am due to sign a renewal shortly and I am seriously thinking now of backing out, which will mean I can leave before go live - and I think will be safer in view of this.

Should I be worried? Suggestions?

[jmo21]

I would only be happy to have this type of clause if:
- I was the only developer on the project
- the requirements were well defined enough that any deviation could in no way be classified as a bug

Even then, I wouldn't be overly keen on it.

"defective services" - makes me even more nervous. A lesson for when you sign your next contract I guess.

[TheCyclingProgrammer]

I have a similar clause in my own contract although to be honest it could probably be better worded.

Bugs during software development are par for the course, especially whilst something is in development and being pushed out to staging servers or for internal alpha/beta testing. I'd consider fixing any bugs like this as part of the job.

Where my clause would normally come into play, would be if I had deployed a production release of an app/piece of software that contained a critical bug that I hadn't spotted and that could reasonably be considered my error, then I would be happy to rectify the issue without further charge although that could be as simple as rolling back the release.

The lines get blurred when the client has their own testing procedures, the software has gone through several staging deployments and internal testing and a bug still gets missed - where do you draw the line? Bug free software is a rare thing.

[CourtesyFlush]

Why worry? It doesn't say how quickly you need to fix them? Is it really such a drain to fix one defect per week and tell them you spent the rest of the time analysing it?

Trying to be clever. Play them at their own game. Can you imagine them explaining to the shareholders why the system doesn't work as an ex contractor is taking his time doing free fixing?

Now MTFU and get on with it. There's benched contractors that read this forum would jump into your shoes.

HTH

[Steelman]

I would only be happy to have this type of clause if:
- I was the only developer on the project
- the requirements were well defined enough that any deviation could in no way be classified as a bug

Even then, I wouldn't be overly keen on it.

"defective services" - makes me even more nervous. A lesson for when you sign your next contract I guess.

Yes - you've nailed both my main points. The requirements have been stretched continually so the final spec barely resembles the original & nw everything is 'a critical bug'. I guess I see a possibility that I could end up working way beyond the project for free - and that would really suck.

I take some comfort that there are no deadlines written in to the completion, but I wouldn't have the money against a client of this stature to argue it in court.

But as this was in the very first one I signed, I guess it will follow me about until I end, so what's the point of worrying about signing an extension now?

Accept; learn; don't repeat.

[SueEllen]

They can argue it in court but as long as you are intelligent enough to document everything especially where the "bugs' aren't clear, then they won't get very far.

[Steelman]

They can argue it in court but as long as you are intelligent enough to document everything especially where the "bugs' aren't clear, then they won't get very far.

I guess the original spec they wrote way back will do. It looks like a totally different system!

First time I'm actually grateful for blurry specs

[GillsMan]

Why worry? It doesn't say how quickly you need to fix them? Is it really such a drain to fix one defect per week and tell them you spent the rest of the time analysing it?

Trying to be clever. Play them at their own game. Can you imagine them explaining to the shareholders why the system doesn't work as an ex contractor is taking his time doing free fixing.

Tbh, this seems like pretty sound advice.

[d000hg]

I guess the original spec they wrote way back will do. It looks like a totally different system!

First time I'm actually grateful for blurry specs

So you've delivered something nothing like the original spec - sounds like lots of things to fix

[Steelman]

So you've delivered something nothing like the original spec - sounds like lots of things to fix

It's been a constanltly moving target my friend...quite possibly the most challenging stakeholders I've worked with in 15 years.