June 22, 2011

Software Engineering Software

I once worked at the world’s largest software company, where I did many different things. I managed projects, managed people, and managed the process of developing software. I notice now-a-days that many people don’t know what types of software to use when developing software. Sure, they know about compilers and debuggers, but they miss out on the most important pieces of the process.

1. The build tool. This is the tool that ties your build process together. A one-man-band developer will often use the build tools integrated into their IDE ( say visual studio or eclipse ), and for simple development, it’s enough. but once you get beyond the one-man-band stage, you’ll need a build tool. Most people use MAKE and its derivatives — though I’m a fan of MAKE+PERL. Perl scripts can wrap make, allowing for things like consolidating errors/warnings from the compiler into a single log, allowing staged makes or distributed makes, and are a lot easier to debug than MAKE.

2. A good bug tracker. We used our own, internally developed tool. FogBugz I hear is pretty good. Without an issue tracker/bug tracker, you’ll lose track of the things you’re working on. A spreadsheet can work for a one-man-band with a small product. Once you get to more than a handful of users, you’ll need a bug tracker. Most bugs are suggestions, not product bugs — you need some way of tracking all those and deciding which ones to implement.

3. Source control system. These systems allow you to track your development, roll-back changes, and otherwise experiment more. It’s like having an “infinite undo”, that works across reboots or sessions. Honestly, why everyone doesn’t use source control amazes me. So many free choices, and they allow you to track your development. Even a one-man-band should have source control, but often don’t. This is one thing I like about XCode — snapshots are a brilliant way to put in basic version control that people may actually use. I’m partial to perforce myself — I find their visual tools to be good to use, and their branch/integration scheme to be straightforward and flexible. Other’s like subversion or GIT — IMHO, subversion is just a poor man’s perforce, implemented badly. GIT I haven’t used, and until I do, I refuse to take a point of view.

4. Static analysis packages. These are tools that run against your binary package, and try to simulate code-paths. They find things like loops/cycles in connecting to a database, unsafe code usage where a potential buffer over-run may exist, etc. They really allow you to develop more robust software that performs better(uses less resources ). These are the hardest to come by and most expensive. I have to give apple credit here — Instruments is surprisingly nice, and giving it away with XCode is a brilliant move to improve the quality of software on their platform. I think it’s part of why there are so many more quality apps in iPhone than on Windows.

5. A Fuzzer. No-one fuzzes their software — I’m sure most people don’t even know what it is. A fuzzer takes a data file and randomly alters it. You then run your software and have it “open” the fuzzed file. Since the file is in some way corrupt, it shouldn’t open. However, since the invalid part is in a random location, your software has no way of knowing that it’s invalid, and will try to open it anyway, injecting garbage into your running code. Most times, this is harmless — but once in a while, it’ll cause a crash. Those crashes are gold — those dumps will often find exploitable places in your code where a hacker could attack your product.

You could add in localization tools or setup package managers — but I think most people know about them already, and hence I’m including them in the “Compiler/debugger/IDE Obvious” part at the beginning.