Monday, March 27, 2006

SBCL devs gettin bank [194.5]

An employee of ITA Software let it be known that his company might be willing to provide a little incentive to speed up the compile times of SBCL in the way of cold hard cash. So far there haven't been any public takers, but sbcl-devel is a pretty low-traffic list. Also, it could very well be that conversations have been taken offline. I found this post interesting because I have been contemplating a similar move to get work done on the win32-side of the house. Bringing the win32 port to parity with Linux would make life much easier for us. There are also some very specific things that are not high-priority items such as executable packaging and tree-shaking that it would be nice to have done. The economics of this are very interesting. We can either fork out serious money and just get a commercial implementation such as LispWorks or Allegro, or we can pony up bounties for people that are already inclined to do the work to bump it up in their prioritization. The benefits going forward in good-will alone make sense, and the bounties would probably cost less in the long run.

Our experience with Microsoft support has definitely opened my eyes to the economics of coding. Sometimes it is simply more cost effective to pay someone else to do the work. I think that all good programmers like to think that they can get anything working. Calling for reinforcements only makes sense if you do it soon enough to make up for the wasted time that would have otherwise been poured down a black hole. A Microsoft incident costs $245. Depending on what you pay your programmers your break-even point will be different, but if it is something you think will take more than two or three days to figure out, you will "save money" by having a Microsoft programmer figure it out for you. I had to put save money in quotes just then because most likely the work you are displacing to your support structure is being done by a full-time employee, and therefore you will be paying them regardless. In fact, you are not saving money in a way that can be tallied up very easily. The real cost savings comes from how much it is worth for your company to ship its product two weeks or even two days earlier. For it really to be cost effective, you probably need to be saving a week or so per call, and there has to be some definite benefit to getting your product out sooner. If you need that product for revenue, it makes all the sense in the world.

The trick is knowing when to throw in the towel early enough on an intractable problem to get the most bang-for-the-buck. Of course, these aren't double-blind experiments here. We only know how long something is going to take to fix after we've fixed it. This is probably a good reason to keep your bug-tracking items up-to-date with estimates of how long it will take to fix. After time, you can get a sense for whether you are a good estimator of bug difficulty. Use the bug-tracking system as training. Once you have developed the skills to accurately estimate what bugs will take the longest to fix, you could do a simple sort of all your current issues, take the ones that have long estimates, and figure out if it is something you could have done by bringing in the big-guns.


Post a Comment

<< Home