For anyone who hasn’t read it there is an excellent programming book out there called The Pragmatic Programmer: From Journeyman to Master. One of the many great topics that they push in the book is the importance of prototyping. They talk about a concept they call “Tracer Bullets” which is a prototype based around simulating the code flow without spending time writing the implementation. One of the best things about this idea is that it can be applied outside of software.
One particularly good example of something that could have benefited from a paper prototype is the CA-17/CA-85 junction just outside of San Jose.
pardon my poor artistry
Let’s say hypothetically I was driving north from Los Gatos on CA-17, and I wanted to go North on CA-85 to head up to Mountain View. I would exit the highway on the right. While on that exit ramp another lane of traffic merges in from the right. That lane of traffic comes from southbound CA-85. Where it gets really nasty is that if the people in that lane want to get onto CA-17 they need to cut across to the left lane. Meanwhile if I want to get to CA-85 I need to cut across to the right lane. If I fail to cut right I end up back on CA-17, and if they fail to cut across they end up back on CA-85 but going North this time.
In the end what this means is 99.9% of the traffic in the left lane wants to go right, and 90% (adding some extra here for people wanting to actually turn around) of the traffic on the right want to get to the left lane. To make this situation worse. If I do manage to get to the right lane, I have to go through the same type of merge crossover again between traffic going to CA-17 Southbound and CA-85 Northbound. If I mess up that one I end up going right back to Los Gatos.
Here’s where tracer bullets come in. A quick paper prototype to simulate the flow of traffic would have revealed the forced crossover pattern, and if I were a moderately sane civil engineer (something slightly less mythical than Bigfoot), I would re-design that road so as to avoid that crossover because it would increase traffic throughput (and probably reduce collisions). I should point out that paper prototyping is covered in a section called “Prototypes and Post-It Notes” in The Pragmatic Programmer.
One of the really neat things about working in software instead of roads however is that we have tools which can help us find this kind of situation. One of the most powerful tools a software engineer has today is their compiler and static code analysis. Many modern static analysis tools will actually evaluate the logic in your code and can help find situations where your logic just doesn’t work right.
Historically there have been several great static analysis tools available. GCC has had basic integrated static analysis for many years, and Gimpel Software’s PC-Lint is an excellent tool. In recent years both Apple and Microsoft have built static analysis tools into their IDEs.
Apple’s Clang based compiler expands on GCC’s Lint-like static analysis and their new Xcode 4 IDE brings static analysis results right into a friendly user interface. You can read all about Xcode 4 on Apple’s Developer website. I will mention that one of the best things about Xcode is the price point. The full Xcode developer toolset is available from the Mac App Store for $4.99.
Microsoft’s new static analysis tools are built into Visual Studio 2010 Ultimate. Personally I can’t speak much about them because I’ve never worked with them. I have taken advantage of Visual Studio 2010’s new -Wall flag and was pleasantly surprised by it. It seems to point out a lot of new compiler warnings that are useful to have. Unfortunately even if Microsoft’s static analysis tool were God’s gift to programming I wouldn’t recommend it, because it only comes with Visual Studio 2010 Ultimate which has an $11,899 price tag. If you’re working on windows you’re better off getting a cheaper IDE and throwing out the $389 for Gimpel Software’s PC-Lint.
Guerilla Software 