Forgot your password?
typodupeerror
Software Technology

Ask Slashdot: How Long Should Devs Support Software Written For Clients? 384

Posted by Soulskill
from the just-until-the-next-venus-transit dept.
lucky4udanny writes "My client says any software/website we develop for them should be supported with bug fixes forever, with no further compensation. We have generally supported our work for two months, to give the client adequate time for real-world testing, after which we charge by the hour for all support. How long should a company fix bugs without compensation in software they developed? What is the industry convention?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Long Should Devs Support Software Written For Clients?

Comments Filter:
  • by Anrego (830717) * on Wednesday June 06, 2012 @06:18PM (#40238013)

    No one would pay the cost to write something that's 100% bug free from square one. Instead, you defer the cost and risks via a support contract. Standard practice and works out for everyone.

    Generally three things should be decided before work has even begun:

    - initial cost of development
    - a warranty period
    - ongoing support agreement

  • by radiumsoup (741987) on Wednesday June 06, 2012 @06:19PM (#40238035)
    I charge people to run Windows Update for them, so I'm getting a kick, etc. ;)
  • by Anonymous Coward on Wednesday June 06, 2012 @06:30PM (#40238155)

    Little bit different - YOU charge, microsoft isn't. They are paying you to read the manual so that you know what button to press, and to press it. They don't want to know about it.

    If you want a car analogy, this would be like paying a mechanic just to check your oil level, because you never could be bothered to find out how.

  • Re:3 Months (Score:5, Interesting)

    by NoNonAlphaCharsHere (2201864) on Wednesday June 06, 2012 @06:44PM (#40238285)
    Too right. Been on the receiving end of that "but our processes have changed" phone call. The analogy I use is "Let's say I'm a tailor who makes a suit for you. Now you gain weight and expect me to fix it for free?".
  • Re:Define "bug" (Score:4, Interesting)

    by ganjadude (952775) on Wednesday June 06, 2012 @06:50PM (#40238345) Homepage
    This happened for a company I once worked for. Microsoft released a windows update to .net back around 2010 that totally bricked our, DOD certified, mission critical systems. (mostly medical, not military) If a backup of the database was run after this .net update, the users would not be able to login to the system. This was accross the board, affected every single system that is out there (10s of thousands)

    nothing that we did was wrong, simply an update of an outside, yet needed (well, not really but you know what I mean) took our entire dev team 3 days to make a fix, thankfully only a few of our major clients were affected.

    point being, unless you code everything yourself from binary, you can not depend on no bug ever creeping into play
  • by icebike (68054) * on Wednesday June 06, 2012 @06:58PM (#40238447)

    On the other hand....
    Forever is a long time. There is no reasonable expectation of forever in any legal contract for goods or services in any
    industry I'm aware of. Even contracts for burial plots do not last much more than 200 years.

    Sure, a wise contractor will have a warranty duration mentioned in the contract, and specify an acceptance testing phase, after which
    all bugs belong to the purchaser. Any bug fixes offered after that are likely to require additional payment.

    Without such a Ts Crossed and Is Dotted contract, there are only reasonable expectations to fall back on:

    Both sides know that there is no such thing as bug free software. Never has been. Never will be.
    Expectations to the contrary are not reasonable, and never have been.
    Expectations of indentured servitude went out with the 13th amendment, and no contract can bring that back.

    Further, rare is the software that enters service and remains unchanged for its useful life. Any warranties or assurances
    are lost once the code is modified, even if modified by the same developer, but especially when another developer
    steps in, or the purchaser themselves make changes. Even without a contract that states this, one need only
    point a finger at the changes made by others to divert ALL blame.

    The two month time period mentioned in the story and "adequate time for testing" seem a little thin if you ask me.
    I would never sign a contract for custom software that was so tightly limited, and it does not sound reasonable for any project of any reasonable scope.

    So without something in writing, the contractor deserves a little pain and suffering (as a stupidity penalty), but they are STILL not up the creek without a paddle, because "forever" is not reasonable, and reasonable expectations become the deciding factor. But in this case "reasonable" is no longer strictly the contractor's call, and courts may well have a say.

  • Re:3 Months (Score:4, Interesting)

    by Jane Q. Public (1010737) on Wednesday June 06, 2012 @07:07PM (#40238543)

    "You have to be careful, because I've had companies that start making changes to their infrastructure, and then told us our software didn't work when in fact their environment changed. So be very specific."

    You should have a specified "scope of work", describing the deliverable. If the situation changes to the extent that anything lies outside the original scope of work, it costs extra.

    I used to work for an engineering company, and that worked for them. Just be sure to specify your scope of work. Then actual bugs that lie inside the scope of work are your responsibility. Anything else is not.

  • Maintenance (Score:5, Interesting)

    by EmperorOfCanada (1332175) on Wednesday June 06, 2012 @07:13PM (#40238603)
    This is what a maintenance contract is about. Generally there are three parts to a maintenance contract. One is that you will charge a set fee for any changes or new work (potentially with a yearly retainer to cover your costs in being ready to do this work) and the other part is that for every year that they pay a fee you will fix any bugs. Often this second part has a year or so included with the initial work.

    The first part of the contract might also cover preventative maintenance such as checking to see that the hardware is functioning, backups are being done, and that nobody is messing with the software.

    Where you really need to cover your ass is in two areas. One is their losses. You can't be responsible for them. If the system is down for 30 minutes during a critical sales pitch they could argue that you just cost them a billion dollars. The other is if they ruin things somehow. If they have someone else mess with the system or they don't do backups, or use sub standard hardware then you need to be able to wash your hands.

    The third critical part is the breakup clauses. If they become a pain in the ass or your company just morphs into something where the old clients are a distraction you need to be able to walk away. The best way (and something they should insist upon) is the source and documentation they would need for them to be able to hand the contract over to someone new in a second. Personally I would refuse to deal with a company that didn't provide this.

    But most of all I would never in a million years commit myself to a company like that. Not just because it would be stupid but also any company that would insist on something so douchey is going to be the biggest bunch of scum to deal with. I could see them insisting that new work and upgrades come under the purview of fixes. "Oh we have moved to a new OS and your software broke." I tried accessing it with an iPad 9 but they don't use HTML anymore so you need to fix that." Then knowing they have you over a barrel they would say, "If you just make it compatible with our new database, OS, and mobile devices we will let you out of the contract in 2 years."

    Lastly maintenance is where many companies make the big bucks. I witnessed where a letter was capitalized and the company billed $1,200. This was in a scripted environment and implemented by a single developer with no complicated QA process. He just logged in directly and VI'd the script.
  • by Midnight_Falcon (2432802) on Wednesday June 06, 2012 @07:18PM (#40238639)

    I have to chime in here because I feel like many of the comments have missed what this is in .."real world" programming: A Sales Opportunity.

    It is inevitable that after a while, your client is going to want new features. If you offer a low rate for bug fixes, or offer a certain # of hours on bug fixes after the original term, you'll keep the channels of communications open with the client; rather than them forgetting about you.

    So, you can act altruistic and offer some amount of free bug fixes..but use the requests for those bug fixes as an opportunity to suggest new functionality/features, or make changes outside of that realm that translate to billable work.

    If you have a proper consulting agreement, any changes outside of bug fixes will already be in scope as a billable activity, so you should be able to bill for that time accordingly.

    I find that keeping lines of communications open with clients after projects has done causes new projects to happen and is a great rainmaker. I think what seems like their thick-headedness is actually an opportunity for you to get more business out of them.

  • by Greyfox (87712) on Wednesday June 06, 2012 @07:20PM (#40238645) Homepage Journal
    Back in the 90's (and still to an extent these days) if you were a really bad programmer you'd just screw around for 3-6 months and then change contracting companies, usually getting a $10-$15K raise in the process. Then the next guy would get stuck supporting your crappy job. Case in point, in the late 90's I got picked up on an inventory project that was already late and over-budget. My predecessor had left in a hurry. Upon reviewing her code, I found that, among other things, she had not realized that in C you have to null-terminate your strings. No accountability must have been nice. It's still pretty damn hard to fire a programmer just for sucking, and it's still pretty damn hard to find good programmers even with the economy as bad as it is. Pretty easy to find bad programmers, though.

    As for this client, you're probably not obligated to anything that's not in writing (IANAL, talk to one.) The "Get it in writing" sword cuts both ways. Tell him you're going to review the support terms in the original contract. Whoops, couldn't find any. Then offer to negotiate some.

  • by networkBoy (774728) on Wednesday June 06, 2012 @07:25PM (#40238679) Homepage Journal

    I don't know what his app is, but I look at it this way (and is how I handle something I write):
    Is this a bug?
    Assuming it is then:
    is this something that is obvious code error (i.e. buffer overflow, null pointer, etc.)? I fix it.
    Is this something that is behavior not as expected, but is not a code error (logic error), and should have been seen as part of acceptance testing? I charge for the fix.

    really simple, and so far I've not had any customers balk.
    -nB

  • by hey! (33014) on Wednesday June 06, 2012 @07:33PM (#40238737) Homepage Journal

    This guy has it right. Deadlines go both ways.

    I once had a client where the project manager handling our contract often sat on deliveries for a month or more before looking at them -- and here I am with a three man development team dedicated to this project. Finally we fly down install the production software and train the users. A week later the project manager is fired and nobody looks at the system for over two years until a new manager starts to procure a system and realizes that his predecessor already paid for one. Word gets to the board of directors, and then we get letter threatening.to sue us for not delivering the system.We have no way of proving to them that we flew a team down there and actually did the installation and training, because everybody we trained had subsequently left the organization. But we had the bills we submitted that were paid by the client, which is at least prima facie evidence we did the work.

    Now we had the source in our source code control system, but so much time had gone by that just getting all the stuff together needed to build and package the system would have been a pain (this is why you should be using maven, folks, which we weren't at the time). And there is no doubt the system was probably so riddled with bugs that getting it working would have taken much, much more work, but the client made it impossible for us to deliver a quality product. The project manager accepted deliveries with only cursory examination, and so late that it forced us to work on this product intermittently, dropping it and picking it up weeks later.

    The lesson is build client responsibilities and support limitations into the contract.

    Standing behind your work doesn't mean delivering unlimited support. It means delivering more than you promised. That starts by setting clear limits and conditions on what you are promising.

"All my life I wanted to be someone; I guess I should have been more specific." -- Jane Wagner

Working...