Fog Creek Software
Discussion Board




Crashing bug?

"For the umpteenth time, I found myself dependent on a code library which had a crashing bug that was unacceptable in code I shipped."

So why didn't you get the source to the library and fix the bug?

.
Monday, October 29, 2001

Do Microsoft provide source to WININET.DLL?

Aaron Lawrence
Monday, October 29, 2001

Not that I know of.

But even if they did, finding and fixing a bug in source code that I've never seen before could well take longer than switching to a less-buggier library or working around a bug.

Joel Spolsky
Monday, October 29, 2001

At times having the source to something is by far the worst situation.  If all you have is a black box then you end up with two results, you either find a workaround or you find an alternative blackbox.  Either way its messy and probably takes far too long and leaves a nasty taste in the mouth.  But once its done its done and having documented it you move on.

If you have the source and you take the fateful step of debugging and isolating the problem and then fixing it what do you have?  You have a millstone.  Unless you can get that fix implemented in some generally available source you are going to have to maintain that fix and so the rest of the code for the forseeable future.

So, then when the next release of your black box comes out with its own subtle differences you get to merge your tiny fix with the new monster and now your debugging not only involves your own code but other people's as well.  Future maintainers will curse you unto the seventh generation.

And this is not that unusual, I've frequently been presented with a 'we just need this, this and this fixing, oh and by the way we need to use this custom version of splinge.lib' 'Why?', I ask.  'Oh we can't remember but it doesn't work without it'.

Open Source, the only blessing that carries its own curse with it.

Simon Lucy
Tuesday, October 30, 2001

> Unless you can get that fix implemented in some generally available source [...]

Well, generally you can. Just send it to the author. Open Source certainly has a lot of downsides, but in my experience this is not one of them.

Guillaume Laurent
Tuesday, October 30, 2001

<quote>
Well, generally you can. Just send it to the author. Open Source certainly has a lot of downsides, but in my experience this is not one of them.
</quote>

It's not that simple.  Case in point, myself :-)

I jhave been developing a utility for the past year (<plug href="http://beust.com/cedric.com/ejbgen" />) and I receive various feedback and source contributions on it.

By the time I get some time to look at those, my own codeline has evolved and very often, in ways that are already incompatible with what the author sent.  I usually end up either ignoring their fix/improvement or implementing it my way, which is not a guarantee that it will please the original contributor.

As for the so-called open-mindedness of OSS developers to incorporate fixes, that's a good one (RMS, Cox, etc...)

Cedric
Tuesday, October 30, 2001

Open source is not a panacea. Suppose I was writing a Linux program, and my program crashed because of a bug in the Linux Kernel, or in the X Window server, or in the Java VM.

Yes, I can write a patch for the kernel or X. But what good does that do me? Do I have to tell all my customers that they must upgrade their X server if they want to use my code? Or wait for the next version of Linux?

Unless you're writing "bare metal" code, you have to have workarounds if you want to deal with an installed base.

Joel Spolsky
Tuesday, October 30, 2001

Joel sez: "Yes, I can write a patch for the kernel or X. But what good does that do me? Do I have to tell all my customers that they must upgrade their X server if they want to use my code? Or wait for the next version of Linux?"

Just distribute a patch with your application, and have the installer apply the patch.

Mike Schiraldi
Sunday, November 04, 2001

I should add: VMWare does this (at least it used to), and it's seamless as far as the user is concerned.

"What directory do you want to install to? What IP should we give the VM? We've discovered that your OS sucks, should we fix it?"

Mike Schiraldi
Sunday, November 04, 2001

Patching an installed operating system because _your_ application needs something or does something that no one else needs is just asking for trouble.

Yes it might well work and seem the most efficient thing to do, how much testing has been done with other applications?  Who is responsible if some unforseen event arises that makes one or all components of the system unusable.

Where is the auditing of these changes, how is the user to know it happened?  How is the organisation the user works for to know what happened 6-9-18 months from now?

Making assumptions about what the user really wants and would like happen is one of the worst examples of 'being nice to people'.

Simon Lucy
Tuesday, November 06, 2001

*  Recent Topics

*  Fog Creek Home