Software development tools I'm grateful for
Mood: grateful
Posted on 2011-09-06 16:42:00
Tags: essay programming
Words: 577

This morning I tracked down a bug with a data breakpoint. Turns out, it was a very stupid bug that I introduced myself last week, so it was a bit like cutting a piece of paper with a chainsaw. But it got me to thinking - I'm really glad we have a full shed of chainsaws when we need them! Here are the tools I use when developing software that I'm most grateful for, with brief descriptions:

- Breakpoints: OK, this is pretty basic, but many of the later things are built on this. Being able to say "stop on this line of code and let me see the values of stuff", as well as single-stepping through code, is good enough to track down most of the easy bugs I come across.

- Conditional breakpoints: Like breakpoints, but you can set a condition that gets evaluated each time and only stops if it's true. Very useful if you have to set a breakpoint in high-traffic areas of code, but you only care about a particular VI that's being processed.

- Data breakpoints: Like breakpoints but more awesomer! Seriously: you give it an address and the program will stop immediately when that value is changed. Very useful for tracking down memory corruptions, or just "what stupid code is stomping on my variable?" type situations. Slows down execution a bit, but it's irreplaceable when you need it.

- Tracepoints: Something I only learned about last month, but in Visual Studio you can configure a breakpoint to output something to the debug window instead of actually stopping. This is invaluable in tracking down weird race conditions and tricky timing problems where actually breaking into the debugger will stop it from happening.

- Source control: Pretty fundamental, but being able to see when a line of code was last changed is occasionally very helpful. (plus, of course, being able to undo whole checkins at once, etc., etc.)

- Remote debugging: This still seems magical to me: you can copy over a small program to any machine, then from my computer I can attach to it and debug it as if it was running on my machine! Great for when a bug requires a bunch of other stuff installed to happen. Made even better by:

- Symbol server/pdb files: We archive all of our official build symbols. So, that means, as long as a remote computer is using an official version of LabVIEW, I can debug it and get symbols to see what function we're broken into, etc. Not always perfect (it can be annoying if your source isn't the same as when the executable was built), but makes my life much much easier.

- VMWare images: a great alternative to needing a physical machine to reproduce a problem on, in case you need a bunch of extra stuff installed. Even better in that it makes possible:

- Replay debugging: This is seriously amazeballs. On a VMWare image, you can try to reproduce a problem. When you succeed, you've basically recorded everything that's happened up to that point, and so you can essentially step back in time to see what went wrong. Think Prince of Persia, but without needing that pesky sand. (also: apparently it makes things kinda slow) I have not had the opportunity to use replay debugging, but I hope I do some day because: wow!

Being grateful for things makes you happy. I'm pretty happy now. What are you grateful for? (or, what did I miss in my list?)

8 comments

Comment from wonderjess:
2011-09-06T17:45:05+00:00
Good documentation! Maybe that's just for low-level programmers, but Mathematica's documentation is in general very good.

Comment from skimmerduk:
2011-09-06T20:38:02+00:00
People who are grateful for good documentation!

Signed: A Tech Writer

Comment from wonderjess:
2011-09-07T06:35:39+00:00
I grateful EVERY DAY. Thanks!

Comment from gregstoll:
2011-09-06T22:15:25+00:00
Agreed! MSDN is a godsend for Microsoft documentation.

Comment from yerfdogyrag:
2011-09-06T23:34:02+00:00
I'll add 'printf' to the list. Only seem to need a debugger every few years.

Comment from brittongregory:
2011-09-07T15:22:40+00:00
Ha! You kids and your fancy "debug tools". ;)

Comment from alteredhistory:
2011-09-10T02:07:10+00:00
* STOB (aka Sync To Old Builds), which uses Source Code Control but is a tool in its own right.

* If debugging using LabVIEW, the ability to break into any function and archive its panel so you can re-run just that subroutine with the same inputs until you get it right.

* ACL2 Theorem Prover takes in code and a set of assertions about the postconditions of that code and generates a human-readable mathematical proof of correctness... or returns a "cannot be proved" message, generally with at least one test case that fails your assertions. ACL2 is specific to reasoning about LISP code, but recent libraries have allowed it to make assertions about other languages when the functions can be mechanically restated as LISP.

* Good old desk checking with a buddy. "Does this look right to you?"

Comment from gregstoll:
2011-09-10T23:34:45+00:00
Yeah, STOB is great, just didn't mention it since non-NIers don't know what it is :-) And I always forget that LabVIEW can do neat stuff like archiving its panel...

This backup was done by LJBackup.