What is the best part about software development? Greenfield projects. You have none of the baggage of the bad decisions you made in the past, and you can create some code and see something new. That’s the attractiveness of this business.
What we get “paid for” is actually dealing with a lot of crap code, some written by us, the rest written by others. Ayende has a great quote, broken English and all:
There are always at least two people in any software project:
They are never the same person, even if just by temporal dissonance.
In other words, we will generally have a thought of “who wrote this crap”, and most of the time, it is our past self.
As tempting as it is, we cannot simply try to create new projects whenever we encounter difficulties or better ways of doing things. We would never get things done.
There are however instances that demand a new project. Here are a few that come to mind:
- Platform is not actively supported or vendor’s development has reached a sunset.
- Another major technology has supplanted the one your using in the marketplace, one that would reduce your codebase significantly.
- You have to re-read nearly the entire codebase to make any changes or you have limited tests, specs, documentation, etc. on a key application. This is a special case, one that’s not very popular and easily ignored when we get busy, but in this event, you want to capture as much of the knowledge from the developers now, this is your “project”.
- Your application is small (e.g. 1 developer, handful of function points), these are the perfect environments for learning new technologies, techniques, etc.
Any others come to mind? Let’s have them!
I was all set to write a riveting article on the importance of application UI response times, but another great little project came up and I couldn’t resist.
Basically, my friend come up to me at work today and asked if I knew of any way to record and save a song she had heard on the internet. It should go without saying that the legalities of this should be investigated a bit before trying this yourself, but in this case, I felt comfortable that we were within the law.
Audacity can do this sort of thing nicely, but the problem is, Audacity doesn’t ship with an MP3 encoder (due to legal reasons, I suspect). I needed to find a simple way to copy lame_enc.dll to the user’s hard drive, and create a registry key in the right spot that points to that dll. There are a lot of ways to do this: a little .NET application, a variety of scripting languages, etc. But let’s think about this for a sec…really, what you’re doing is a lot like what an installer does. InstallShield, Wise Installer, the installation wizard that comes with Visual Studio, WiX…all these are great, albeit a bit expensive and/or confusing. Did you know there are two great, free alternatives? Inno Setup and NSIS are both quite robust, fully scriptable, free installation packages. As an aside, I’d encourage you to not underestimate the significance of having your installer be totally scriptable…just being able to follow the version of your installer via a source control system is immensely helpful. And if you’re stuck with Windows Installer, check out WiX…it’s great.
Out of the free options, I tend toward NSIS for several key reasons:
- Helpful support community
- Used by Google
- Very small install files (smallest of all installers)
There are several IDEs to help you create and maintain NSIS installers. I choose HM NIS Edit simply because it was first one I saw years ago (before all the others were available). It has a nice little wizard that can help you build a simple installer script very quickly.
I walked through the wizard and chose lame_enc.dll as the only file that this installer will install. I decided to put it in Program Files, since I assume that most users know not to randomly delete files from there. Plus, it sort of fits there 
.
Now, all, we need to do is add the registry key that tells Audacity where to find lame_enc.dll. The NSIS documentation is very helpful, and I found the answer in no time:
WriteRegStr HKEY_CURRENT_USER "Software\Audacity\Audacity\MP3" "MP3LibPath" "$PROGRAMFILES\LAME MP3 Encoder\lame_enc.dll"
My NSIS script already had a block of code called “MainSection”. That block contains the operations that happen when the installer runs. I just added my new operation to the end of the main section, and added a corresponding DeleteRegKey operation in the Uninstall section, and voila! The installer was done. Well, done after I compiled it, of course. Now, all I need to do is point my friend to the Audacity installer, and the LAME MP3 Dll installer I just wrote in 3 minutes, and she’ll be making her own mp3s like a pro.
Oh, and remember when I said that NSIS makes small installers? Well, the dll we’re installing here is 296KB, and the installer? It’s 219KB. Isn’t that refreshing?
I hope every developer has a chance to spend some quality time learning how modern installers work. That knowledge comes in handy more times than you might think. Check out NSIS and Inno Setup for starters…they’re so simple to use, I bet you’ll find yourself thinking of ways to use them before you know it.
Helpful links for this article: