4

If a developer made a database design choice (too short field length) 3 years ago on a project, should the development studio or customer be expected to fit the bill for any time taken to fix.

It was only small so we did it for free, but I just wandered what's the norm?

Comments
  • 3
    Charge for it, obviously. Are you fixing bugs for free too?
  • 1
    Was the dev hired / contracted by the studio?

    Was the database design and implementation sold to the customer, or leased in a contractual subscription model with on going support and maintenance?

    Depending on your answers, you should be able to answer your own question.
  • 4
    It's only a bug if the original spec has not been fulfilled. If there is no original spec, then it is automatically fulfilled.

    A "spec" however might also be some sort of description or use cases or anything like that which doesn't contain the length spec, but describes the usage so that a dev should have been able to conclude back then that the field length had to be a little longer.

    Either way, if you aren't Oracle, then it's probably a good idea not to fuck the customers over a minor update no matter whose fault it was.
  • 1
    @gronostaj Charging for having screwed up isn't reasonable, and at least within a certain time period, it's not even legal. Provided that it actually is a bug and not the customer trying to get a change request done for free.
  • 2
    It's a change request. Of cause you charge them !
  • 2
    @Fast-Nop He didn’t screwed up. For 3 years softawere was conform to specification. Then they decided to change specs with more data.
    It’s a change. They pay.
    I used int32 as Ids in most of my projects. So when one of them (probably never) runs to max, It’s not my job to change it to int64 or guid. (I use only guid now tho)
  • 0
    @NoToJavaScript You can't know whether it has been conform for three years, only that it has been working. But that may as well just be because the customer hadn't been using it in that area of the spec.

    Using these 32 bit IDs is fine as long as that is documented AND signed off by the customer, even if it's buried deep down on page 150 of the system documentation.
  • 0
    @Fast-Nop It was accepted. Depending on project, but I never saw “3 years bug fix guaranty”. Usually I give 60 days.
    It doesn’t matter if it was a bug or not. Client accepted software. Free bug fix period ended. Now they pay in any case.
  • 0
    @NoToJavaScript Depends on the contract. If it was accepted AND the vendor signed off the docs, and now it turns out the vendor hadn't quite implemented what he documented he had, then he can't take money for that.

    Because if you sell stuff that doesn't do what you claim it does, and you don't even want to put it straight afterwards, prepare to get sued. Also, 60 days is ridiculous.

    You know how this looks? Trying to rip off the customer for shit you have botched up.
  • 1
    @Fast-Nop And that’s why I put everything in my spec docs. I find this part is even more important than code it self.

    And I mean including even what datatypes will be used, protocols, platform. And specially what will not be in the final product. I will add most of things they will ask me anyway as “Additional cost”. You want sorting on your tables? Additional cost. You want grouping? Additional cost.

    And all of these is based on their budget. If I feel like they have enough budget, I would quote these “additional cost” directly in the project definition.

    Anything what is not explicitly stated in the docs will not be done and is a change request.

    They read, sign and accept these definitions.
    If they want to change anything: I’ll bill them.
  • 1
    @Fast-Nop And 60 days (for small/medium project. Not talking about ERP level) is more then enough. If they wait 3 months before starting tests, I’ve moved already on another project. Thier fault. So fuck them.

    My product will always respect the initial definition. But if in a year you come to me and say “it doesn’t work when XXX” and XXX wasn’t part of original use cases : Bill them.
  • 0
    @NoToJavaScript Ahhh there you go, it's part of the spec docs that the customer has to sign off. Yeah then you're right, that wouldn't be a bug fix, it would be a change request, and that will cost for sure.
Add Comment