Thursday, September 29, 2005

Software that's built to last

An article on the Windows Vista release tells the story of how Microsoft realized (belatedly) that their development practices no longer supported the release of their software. Microsoft lost a tremendous amount of time because their software wasn't flexible enough to handle the changes they wanted to put into it.

Take a look at the applications you use on a daily basis. When was "1.0" of your internet browser released, your email program, the instant messenger program, your music player. In many cases, it's only been around 4-5 years. "Windows", even the NT codebase, has been around since 1992. LabVIEW was first released in 1986. How in the world do you write code that still runs twenty years later?

Most software products change by the addition of features. We add new capabilities that customers are willing to pay money for. The ease of adding those features is directly related to the architecture of the code. A "good" architecture makes adding features easy, a "bad" architecture makes adding features hard. Unfortunately, it's not really that easy. When NI started writing LabVIEW, "networks" were in their infancy (remember ARCNET and token ring? NI actually used GPIB cables to send data between machines at one point). Who knew that one day we'd be doing data servers, remote panels, and web browsers integrated in to LabVIEW? Feature needs change over time. Unfortunately, architecture is much harder to change and it requires real work, it doesn't just happen on its own.

So, have you ever bought software with the bullet point "rearchitected for better developer maintanability!" I don't recall that one making it on "LabVIEW Key Benefits" list. Our customers don't pay for it directly and your customers don't buy your software because you made improvements. But, if you want your software to last, you need to invest in architecture changes. Features pay the bills this year, architecture pays the bills next year. Learn how to refactor, or else you will end up with a rewrite.

Tuesday, September 13, 2005

Remembering your work

Whenever you have multiple developers working on the same file, be it a program source file, a graphics file, or even documentation, they are going to start stomping on each other at some point. A team typically turns to a source code management system (SCM) to help with this problem. However, most individual developers don't ever use these systems and that's a shame. The beauty of an SCM system is that you can still recover from an "oops" after you accidentally hit "Save" instead of "Save As...". You can get your precious work back if your filesystem corrupts that all important file. And, the way I use it most, you can go back and figure out why your system worked better before you added that last "feature".

I've used many different systems over the years but there are two packages out there that I recommend most for the personal user. They are both industrial strength (because you always end up needing it) but are user friendly enough that I think most any developer could figure them out. They are cross-platform. And, most importantly, they are both free for personal use.

The first is Perforce. We use it internally at NI and it's quite good. Even though it can handle our more than 5 million files, it really works well for just a few files also. You just download the client and the server and run them on your laptop, desktop machine, or whatever. It works over the network if you need it to.

The second is Subversion. It's an open source SCM system that is trying to replace the open source standby CVS. We're using it on the LabVIEW Embedded Development Module public repository and so far it's working nicely. It is much much easier to use than CVS but it has the features that I care about. There's a windows shell extension called TortoiseSVN that makes all of the management rather easy. I found a blog with some links that are probably useful.


FREE hit counter and Internet traffic statistics from