1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Support duration?

Discussion in 'Embedded' started by Don Y, Sep 22, 2011.

  1. Don Y

    Don Y Guest

    Hi,

    What sort of policies do (contract/free-lance) folks follow
    for post-release support?

    As a matter of policy, I fix bugs (errors in an implementation,
    *not* a specification!) for free "indefinitely".

    I also make myself available for enhancements/modifications
    (for pay at "current rates") for "some time" after initial
    release. In the past, that was 5 years. Then, 2 years.
    Nowadays this seems like an eternity...

    I'm now thinking about cutting that to "0 years" (i.e., to cut
    my future commitments) and bug fixes to ~1 year (still free).

    Note that I provide complete documentation for my projects
    (schematics, artwork, specifications, source code, etc.)
    so I *shouldn't* be "needed" in any of these cases.

    I'm just a bit concerned as to how clients will receive this
    policy change on my part...

    Thx,
    --don
     
    Don Y, Sep 22, 2011
    #1
    1. Advertisements

  2. Don Y

    srl100 Guest

    Hi,
    How about making your "retainer period" a separate, negotiable part of you
    contract? If a customer does not perceive any value in keeping yo
    available then they can opt to strike out that part of the contract. I
    they see value in retaining you then they will pay. Either way, you wil
    both know where you stand.
     
    srl100, Sep 22, 2011
    #2
    1. Advertisements

  3. Don Y

    Don Y Guest

    Sorry, perhaps I wasn't clear. :<

    I *intend* to change the terms to:
    "... fix bugs, at no cost, for 1 year from release date; no
    commitment to future development."

    My question is: "How typical/atypical is this (for other developers)?"
    and "How much resistance is it likely to meet among clients?" I.e.,
    my current policies are considerably more generous than this.

    E.g., if others routinely fix bugs on a T&M basis, then my terms
    are more generous wrt bug fixes. Similarly, if other developers
    routinely agree to be available for N years after release, then
    my terms, in that regard, would be *less* generous.

    Given my own experiences, the bug fix clause is rarely an issue
    (I don't release buggy software. Of course, being good at writing
    specifications loads the dice in my favor!). The "ongoing support"
    clause could be alarming to some clients (I have some designs that
    are in production for more than a decade; people seem to like the
    reassurance that they *can* come back for "enhancements" long after
    the original contract is completed).
     
    Don Y, Sep 22, 2011
    #3
  4. Don Y

    Tim Wescott Guest

    I do just about everything on a per-hour basis. If my client comes back
    later and wants more work done, whether its fixes or extensions, it's per
    hour. I do try to give them priority in the queue, when that is possible.

    If I did work per-job then I'd have to consider warranty repairs. But so
    far that hasn't cropped up as an issue.
     
    Tim Wescott, Sep 22, 2011
    #4
  5. Consider offering a 'coupon' (or 2 or 3) for any support after some
    initial warranty period. Say, 90 days warranty after implementation
    and ,after that a coupon that expires in 90 days, one the expires in
    180 days, and one the expires in a year. That way, the customer can
    really only bug you for minor things in the beginning. Of course,
    regular rates would come into play after a year.

    You can alter the times - just an idea. And if they use all 3 coupons
    quickly - that's their decision.
     
    1 Lucky Texan, Sep 22, 2011
    #5
  6. Don Y

    Don Y Guest

    Hi Tim,

    So, you don't deal with complete projects but, rather, work on
    "whatever", "whenever" and "for as long as" they want? I.e.,
    not goal driven.
    I guess we're in different situations (since there doesn't appear to
    be a logical "end" to your task(s)) -- but, there may be some parallels.
    I.e., how would your clients take to the idea that you were "too
    busy" (or simply "not interested") in doing more work -- on a
    project that you were "lead" on, previously?

    Would they feel abandoned, betrayed, etc.? Or, simply inconvenienced?
    ("Oh, well... we'll have to find someone else to maintain this
    product... BUT, we *have* everything we need to do so, just need the
    *person*!")
    I see warranty as not just related to per job vs. per diem work.
    I.e., if you wrote a piece of code to do "X" and a bug was later
    discovered in that code, would you *fix* it? Or, do you have
    *no* specific "deliverables" -- other than "attendance"?
     
    Don Y, Sep 22, 2011
    #6
  7. Don Y

    Don Y Guest

    I'm not worried about "warranty" -- if I screwed up, *I* fix it.
    I cap the time that I allow you to find and report problems to
    me -- simply so I don't get a call 26 years from now saying,
    "There's a bug in your *date* handler...".

    Note that modifications, extensions, etc. are NOT part of the
    warranty. We agree as to what the project will entail. We
    formalize that in a specification. I then implement that
    specification, faithfully. You sign off that I have satisfied
    my contractual requirements -- the product does what it was
    intended to do (insofar as one can test it at sign-off).

    If you, now, want to change some aspect of the design or add
    some feature or start work on Version II, then that's a separate
    project. *Not* covered by the warranty's terms (i.e., I won't
    "fix it for free")

    What I'm more concerned with is making it pretty obvious to
    clients that "I reserve the right to NOT do followup work
    for you". (Note that this is implicit in most relationships
    but my previous contracts have explicitly *stated* that I
    would be available "for some period of time" for followup
    work -- though the terms of that work would be negotiated
    separately!)

    I'm afraid that this can scare clients: "What if we want to make
    some little change? We'll have to *find* someone to do the
    work for us (which is a "search cost" that they will have to incur),
    *hope* that the person we find is able to pick up where you
    left off (always a crapshoot bringing on new talent!) *and*
    hope the changes that we want are consistent -- in that new
    developer's eyes -- with the implementation you have given us!"

    Realistically, there is nothing different, here, than how things
    have been all along -- except that in those cases where I have
    a *choice* regarding my labor offerings, that I would *consent* to
    their needs. OTOH, if I got hit by a truck, laid up with a
    prolonged illness, etc. they'd still find themselves SoL
    (the risk of hiring contractors)
     
    Don Y, Sep 22, 2011
    #7
  8. Don Y

    Tim Wescott Guest

    Different goals. Most of what I do is algorithms and software bits for
    implementing control loops or signal processing into their software base
    -- so it's not so much "not goal driven" as not a complete shrink-wrapped
    package.
    That's a dilemma -- how would my current clients feel if I suddenly said
    "oh, sorry, some old work cropped up and I need to drop you for a
    while". I try to be as fair as possible, given the circumstances.
    If a bug as discovered I'd certainly feel that I should make myself
    available. Depending on just how stupid I felt about the bug, and how
    thoroughly the customer tested when they passed the software in the first
    place, I would charge for more or less of the work.

    I guess the difference is that I have no set policy -- I take things on a
    case by case basis. And, for the algorithmic stuff, it's rare that a
    real _bug_ will make it through initial testing. All I can think of is
    if the algorithm didn't take care of some corner case, and it was one
    that I didn't warn the client about in advance (because, with nonlinear
    control, you pretty much cannot take care of _all_ corner cases -- you
    can only identify the space within which your algorithm will be valid,
    and advise on how to stay within that space).
     
    Tim Wescott, Sep 22, 2011
    #8
  9. Don Y

    Don Y Guest

    Hi Tim,

    [much elided]
    But, if (for example) you didn't put a clamp on the integrator and
    it was eventually deployed in a situation where it not only "wound up"
    but actually *overflowed* (consider a process where the setpoint is
    beyond the practical range of the process... setting a furnace to
    1200C but the gas supply is sized such that it will never attain
    that!). You could argue that this is a bug or a "misapplication".

    Regardless. Who pays to have it fixed?
    [Flip side: current clients, some months from now, have production
    *stalled* because of an issue that has come up with your design
    (hardware or software). How will they feel if you *don't* "drop
    everything" and attend to their needs? This is how I differentiate
    between "repairs" and "new, though related, work"]

    Note that, in my case, the scenario is more like:
    "Wow! I'm thrilled that Model I has been so successful for you!
    But, no, I won't be designing Model II for you..."
    Fair enough. I don't want to get into a "who's-fault-is-it" argument
    with clients. That's why specifications are so important to me!
    If it's in the spec, my design has to meet it. OTOH, if it is
    NOT specified, I can do whatever I want -- intentionally or
    UNintentionally.

    [When developing a spec with a client, any time they respond to
    one of my "What If's" with "I don't care", I say, sotto voce,
    "When <whatever>, the device can erase all memory and burst
    into flames...". After the second time I make this comment,
    clients are aware that they *should* care about these issues.
    If they *really* don't think they will ever happen, then they
    can be comfortable with the "burst into flames" scenario.
    After all, it will probably SAVE them development dollars!]
     
    Don Y, Sep 24, 2011
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.