I intend to return to daily blogging within a few weeks, but I’m going to surface temporarily to talk about programming tools.

It didn’t take long, working on Project M, before I realized that my software development tools needed an upgrade. First off, bug-tracking software. I didn’t have any.

With Project Badger, I needed it, but didn’t realize that I did. I managed to muddle through by keeping a text file of open issues, a very detailed revision history in the program’s documentation for closed ones, and extensive e-mail archives. It wasn’t pretty… among other things, it wasn’t very good for keeping track of ideas for new features, so I tended to implement them on an as-needed basis, without much long-term planning. But it did the job so far as my customers were concerned, and I didn’t know of any better way.

When BigCo bought the company, I was introduced to their bug-tracking software. Their crap bug-tracking software. It got the job done, but it was obviously designed more for keeping track of programmer time for accounting purposes than anything else, and it was painful to use. Nevertheless, it opened my eyes to the possibilities, and after some time and research, I decided to recommend Fog Creek’s FogBUGZ for our team instead.

FogBUGZ worked, and worked very well indeed. We’re still using it. But of course, the license for it belongs to BigCo, not my company, and I needed something for Project M and any new projects I came up with. I really like FogBUGZ, but my company budget doesn’t presently stretch to cover FogBUGZ price. I looked at several free alternatives, but it didn’t take long to realize that they were universally craptastic, so I started looking at lower-cost alternatives.

I finally decided on Atlassian’s JIRA. It has a 30-day free trial, I could set it up locally on my Linux system to try it out, and best of all a “starter license” (which is plenty for my current needs) is only $10. A year. So I loaded it up and tried it out.

It wasn’t an entirely smooth transition, but once I got up to speed on it, I found JIRA to be very capable. Not quite as polished as FogBUGZ in some respects, but a little more polished in others. It does the job, and does it well, so I happily paid my ten dollars.

Next up, I needed something to put it on. I’d originally installed it on a virtual machine on my laptop system, but that stretched the laptop’s capabilities a little further than I like. A visit to our local Best Buy produced an el-cheapo desktop machine, which now resides in a corner of our office, sans keyboard, mouse, or monitor. It didn’t take long to put a copy of Ubuntu Linux on it, and it now supports both an instance of JIRA and the company’s Git source-code repository. For security, it’s tucked away behind our firewall; the only Internet-facing evidence that it exists is a single non-standard Secure Shell (SSH) port, configured to allow access solely via public-key authentication, by which I can tap into it whether I’m at my desk or twelve time-zones away. Have I mentioned that I really love technology? 😉

A few weeks ago, I realized that I also needed a better build system. I’d been using the build system that’s part of the editor and development environment I’m presently using, but as Project M gets larger, its limitations have become progressively more apparent, and progressively harder to get around. When I realized last week that I needed to refactor the project into several modules, and the amount of pain that I’d have to go through to do that, I decided it was time to grit my teeth and make the switch.

Unfortunately, I didn’t know of a viable alternative. I knew I could get the venerable “make” program to do it, but I’ve written and maintained makefiles before, and without non-standard extensions they’re a real pain to keep up to date. There are a number of make-style replacements too, but which ones are even worth looking at?

I finally decided on SCons. Most make-style programs have their own mini programming language, but SCons takes that to an extreme — it uses a real programming language, Python. That’s what decided me: it’s not perfect, but with the power of a full programming language behind it, it provides all the flexibility that I could possibly need. It took a couple days to get high enough on the learning curve to convert Project M to it, but it’s pretty much done now, and it’s very nice.

I’m still looking for the perfect programmer’s editor, but not too seriously. I’ll probably end up writing my own some day, but there’s too much else to do right now. For the moment, I’ll have to be happy with what I’ve got.

One last note. I had reason to use Subversion again tonight. It has been a couple of years since I’ve used it much, and I had to do a lot of fumbling around before I finished what I was doing. Git is so much more advanced, and easier to use, that it just plain ain’t funny. Joel Spolsky had a point last year.