5 ms·

You have an astounding dedication to your craft.

by thaumaturgy 15y ago

cperciva 15y ago
It makes me sad that this is considered abnormal, never mind astounding.
- jgrahamc 15y ago
  I agree with that sentiment. I have a piece of C code that I license to companies (it does multi-label classification of documents---mostly email) and I have very good test coverage and have been obsessive about its design and operation. Since it does a lot of low level C tricks for speed I wanted to be absolutely sure that it wouldn't crash, and it has to work on Windows (32 and 64), Solaris, HP/UX, AIX, Linux, ... The bottom line is that being obsessed about the stability of the code has meant that in the five years it's been shipping not a single client has reported a bug and I have never heard of the code crashing. This actually turned out to be a problem for me, because I had a hard time getting some people to renew maintenance on the code because it never failed.
  - TheAmazingIdiot 15y ago
    I deign to mention it, but if you were to add in a "bug" that would safely 'crash' at sparse but random-ish intervals, you could charge for maintenance. Maintenance would consist of lowering the multiplier of "crash" occurance. So your Program is always improving. I see little difference between this and the way hardware makers cripple lower end hardware You can sell maintenance then. Slimy, i know. But business is business.
    - nawariata 15y ago
      Using the car analogy, crippling hardware to make it slower is an equivalent of putting speed limiter on an engine (admittedly for different reasons) which still makes it fully operational. Purposefully introducing bugs is like making airbags go off at random times so you could charge for service. Nice business practice.
    - jacques_chester 15y ago
      This tactic might exist in the wild, based on some stories I've seen on DailyWTF, but I would be amazed if it didn't result in lawsuits. One of these days those "no liability" clauses are going to be removed by legislation or a blockbuster court case and whole sewerage plants are going to smash into fan factories.
  - yuvipanda 15y ago
    Just curious - did the fact that it was hard to get people to renew maintenance contracts have any effect on your code quality at all?
    - jgrahamc 15y ago
      No, I take bugs personally. If you actually take bugs personally they hurt and you don't want to have to deal with them. Thus you make them go away.
      - ColinWright 15y ago
        For literally decades I have advocated this attitude. Time and time again my efforts are beaten back with "Bug-Free doesn't sell" and "Bug-Free doesn't pay" and, most insidious, "Bug-Free is impossible." This last is then followed by * You have to verify the compiler, * You have to verify the hardware, * You have to verify that there wasn't an error in loading the code, * You have to use radiation-hardened hardware * ... and so on. They miss the point! Bugs in your code are way more likely than any of the other problems, and they matter. I've generally given up, but at least it's nice to see the attitude here not being instantly shouted down.
        jgrahamc 15y ago
        I'm with you on "Bugs in your code are way more likely than any of the other problems, and they matter." This is very true. A while back Eric Raymond had a post called "When you see a heisenbug in C, suspect your compiler’s optimizer" (http://esr.ibiblio.org/?p=1705 http://esr.ibiblio.org/?p=1705) which I felt was very wrong and responded with "A bad workman blames his tools" (http://blog.jgc.org/2010/02/bad-workman-blames-his-tools.html http://blog.jgc.org/2010/02/bad-workman-blames-his-tools.htm...). As might have been predicted the bug that Raymond was talking about wasn't caused by the optimizer at all (http://esr.ibiblio.org/?p=1705#comment-248328 http://esr.ibiblio.org/?p=1705#comment-248328). It's depressing to think that when your code works, it's almost always your fault.
        15y ago
  - cperciva 15y ago
    This is why I've never believed in the "charge for support" model for funding open source software -- it creates a financial incentive to have hard-to-use bug-ridden code. With Tarsnap, my incentives are perfectly aligned: Writing good code results in happy Tarsnap users, which results in more Tarsnap users.
    - cookiecaper 15y ago
      Well, "charge for support" works for amalgamations of code like Red Hat, but I agree it's probably not ideal for individual projects (at least small projects). I prefer offering services related to the code -- not only bugfixes for cash, but also new features and installation. CodeWeavers develops WINE this way and I think they're doing pretty well.
- antifuchs 15y ago
  Let's say an admirable dedication to your craft, then. I'm definitely glad you put out these bounties - you set a very good example for us all.

You have an astounding dedication to your craft.

cperciva 15y ago

It makes me sad that this is considered abnormal, never mind astounding.

jgrahamc 15y ago
I agree with that sentiment. I have a piece of C code that I license to companies (it does multi-label classification of documents---mostly email) and I have very good test coverage and have been obsessive about its design and operation. Since it does a lot of low level C tricks for speed I wanted to be absolutely sure that it wouldn't crash, and it has to work on Windows (32 and 64), Solaris, HP/UX, AIX, Linux, ... The bottom line is that being obsessed about the stability of the code has meant that in the five years it's been shipping not a single client has reported a bug and I have never heard of the code crashing. This actually turned out to be a problem for me, because I had a hard time getting some people to renew maintenance on the code because it never failed.
- TheAmazingIdiot 15y ago
  I deign to mention it, but if you were to add in a "bug" that would safely 'crash' at sparse but random-ish intervals, you could charge for maintenance. Maintenance would consist of lowering the multiplier of "crash" occurance. So your Program is always improving. I see little difference between this and the way hardware makers cripple lower end hardware You can sell maintenance then. Slimy, i know. But business is business.
  - nawariata 15y ago
    Using the car analogy, crippling hardware to make it slower is an equivalent of putting speed limiter on an engine (admittedly for different reasons) which still makes it fully operational. Purposefully introducing bugs is like making airbags go off at random times so you could charge for service. Nice business practice.
  - jacques_chester 15y ago
    This tactic might exist in the wild, based on some stories I've seen on DailyWTF, but I would be amazed if it didn't result in lawsuits. One of these days those "no liability" clauses are going to be removed by legislation or a blockbuster court case and whole sewerage plants are going to smash into fan factories.
- yuvipanda 15y ago
  Just curious - did the fact that it was hard to get people to renew maintenance contracts have any effect on your code quality at all?
  - jgrahamc 15y ago
    No, I take bugs personally. If you actually take bugs personally they hurt and you don't want to have to deal with them. Thus you make them go away.
    - ColinWright 15y ago
      For literally decades I have advocated this attitude. Time and time again my efforts are beaten back with "Bug-Free doesn't sell" and "Bug-Free doesn't pay" and, most insidious, "Bug-Free is impossible." This last is then followed by * You have to verify the compiler, * You have to verify the hardware, * You have to verify that there wasn't an error in loading the code, * You have to use radiation-hardened hardware * ... and so on. They miss the point! Bugs in your code are way more likely than any of the other problems, and they matter. I've generally given up, but at least it's nice to see the attitude here not being instantly shouted down.
      - jgrahamc 15y ago
        I'm with you on "Bugs in your code are way more likely than any of the other problems, and they matter." This is very true. A while back Eric Raymond had a post called "When you see a heisenbug in C, suspect your compiler’s optimizer" (http://esr.ibiblio.org/?p=1705 http://esr.ibiblio.org/?p=1705) which I felt was very wrong and responded with "A bad workman blames his tools" (http://blog.jgc.org/2010/02/bad-workman-blames-his-tools.html http://blog.jgc.org/2010/02/bad-workman-blames-his-tools.htm...). As might have been predicted the bug that Raymond was talking about wasn't caused by the optimizer at all (http://esr.ibiblio.org/?p=1705#comment-248328 http://esr.ibiblio.org/?p=1705#comment-248328). It's depressing to think that when your code works, it's almost always your fault.
        15y ago
- cperciva 15y ago
  This is why I've never believed in the "charge for support" model for funding open source software -- it creates a financial incentive to have hard-to-use bug-ridden code. With Tarsnap, my incentives are perfectly aligned: Writing good code results in happy Tarsnap users, which results in more Tarsnap users.
  - cookiecaper 15y ago
    Well, "charge for support" works for amalgamations of code like Red Hat, but I agree it's probably not ideal for individual projects (at least small projects). I prefer offering services related to the code -- not only bugfixes for cash, but also new features and installation. CodeWeavers develops WINE this way and I think they're doing pretty well.
antifuchs 15y ago
Let's say an admirable dedication to your craft, then. I'm definitely glad you put out these bounties - you set a very good example for us all.