I'd add that in my experience, typing the 30 to 40 lines of assembler code is apt to be more error prone than typing one line of perl; so the odds of there being a bug due to a mental lapse while typing goes up. (A BSE instruction is not the same as a BSR for example...). It also takes longer to read the code (30 lines of it).

I'd agree that debugging tools have a massive impact on debugging time: using the perl debugger saves me a lot of time, as does gdb. Setting breakpoints at suspicious places, and being able to narrow down flawed code by single stepping through functions that are misbehaving until I get to the broken code is a huge timesaver.

Yes, I can get the same results "by hand", using trace statements or the like, but it takes many more runs get the same results, and I have to keep tinkering with the code, fixing stupid syntax errors in my debug statements, and so forth.

And on some systems, the core dump file you get isn't compatible with your debugger, so you either need to read it by hand (ick!), or run the whole program through the debugger for a while, and wait for it to die, so you can check the stack trace...yuck!

A good debugging environment is wonderful. A test suite that includes comprehensive regression tests is even better.

Lines of code give me a rough estimate of how much work is in the project, and how much can go wrong if I assume it's all a tangled mess just waiting to fall apart. It's a starting point for estimates of how long it will take to maintain code, assuming that the code is riddled with ridiculous side effects that shouldn't be in there, but are anyway. All too often, this assumption will turn out to be correct.

-- AC