Most people working in small software shops know of and read Joel Spolsky. Not only does he write about technical aspects, he also comments on the business of software and how to make a business out of software.
This is a cautionary tale, a what not to do when faced with a bug comes and goes and seems intractable.
We are working on a customer project with an O/RM persistence layer. We're using NHibernate, and up until recently, it's been a joy to work with. I say recently, because about a week ago, our project started to load from and save to the database in an increasingly slow fashion.
In one of our projects, we need to parse some date/times that we are getting back from scans of documents. In about 500 documents, we had about 10 whose date format we couldn't figure out:
D:191040305125916
Was is epoch time? Some kind of offset counter? 100-nanosecond ticks from January 1, 0001?
The 19 at the front is a clue -- it turns out this is a Y2K problem, probably created from the original document creator's bad use of Perl.
After my post on CruiseControl.NET and Sandcastle, one of my many (okay, 29) Twitter followers asked "Do you look code quality or test coverage as part of your automated builds?" Test coverage is another post, but I'll talk a bit about code quality.
Following up on what Jamie had to say,