However, that’s not a big deal

Along the way, I needed to look at a lot of ‘printf’ output. Normally, our software doesn’t spew a lot of debug information. We print a certain amount my default because it allows our customer to self-diagnose to a degree – but if we print too much, the customer freaks out and that makes more work for us when a vast majority of all of our output is purely informational. Even some messages that say things like “ERROR! THE WORLD WILL EXPLODE IN 10 SECONDS” can safely be ignored, so we keep most of our debug output off.

What that means to me tonight (this morning) is that I need to turn it on. Ok, great. There’s one line in a config file somewhere, right? Or maybe just one runtime “knob” (that reminds me, I should write a post about knobs) that can be turned? Heh. Wrong.

I haven’t finished counting yet, but I can think of a minimum of 5 different ways to turn on debugging output off the top of my head. Oh, what’s even better is that they aren’t even consistent. One file has a global variable called ‘enableDebug’ that is checked in some files, and another file will have a global called something else, used by a different (and sometimes overlapping) set of files. Still better, a header file somewhere will have a macro like this:
[code lang="c"]
#if 0
# define TRACE printf("[%12s:%3d]", __FILE__, __LINE__);printf
#else
# define TRACE
#endif
[/code]

and a construct like the following somewhere else:

[code lang="c"]
if(enableDbg)
TRACE("something");
[/code]

What does it mean when you have the above in about 483 various places spread out over 85,000 lines of code? It means I have to run the software a hundred times just to make sure I’m printing everything I need to see in order to properly analyze my problem. Clearly, we need to revamp our software so that debugging output is centrally controlled and consistently applied. A nice logging framework would be nice. We’d have to write it ourselves (I’m in the embedded world, you see), but it should be done.

But I can’t. And we can’t. There’s no money or time for it – and that’s just the way it is. The reasons it can’t happen in my business are different than those for a business in some other industry, but the outcome is the same. More generally, I come across things almost every day that scream out “Please! Kill me! Replace me with something that has been thought out for 5 minutes!”, but it’s not that often that I can do anything about it, and rarely do I ever have specific direction from management to do anything about it.

But why? Isn’t there inherent value is making software better? For every 5 minutes I spend making it better now, doesn’t that mean that some poor sap down the road saves about 30? Forget how line counts play into cost estimating – isn’t it inherently valuable to keep your code size down, and even more valuable to keep it’s complexity down?

The answer to all those questions is “Yes.” Then why don’t companies task their software developers with making their software better?

Here’s why: because it rarely produces any additional value to the customer, and almost never produces any value to the customer that the customer would be willing to pay for. I’m not the most experienced among us, but my experience so far has taught me that the purpose of the software is to be valuable to the customer defined on his own terms, which directly translates into value to me (the company).

Yes, it’s true that it’s a royal pain in the rear to deal with the debugging output issue I described above – but the 100 hours I’d spend fixing it (and probably more, if truth be told) creates little or no value to the customer, and none that he can perceive – which means he won’t pay for it, which means that it wouldn’t directly translate into value to the company. There is an implied value later on down the road, but it’s one that can never be measured, and thus the company doesn’t have much interest in “making software better” generally. It’s painful to people like me because I want to create software I can be proud of, which ideally means creating the best software I can create; it’s an art, a science, and a matter of craftsmanship – but I have to be focused on the value the software truly represents, and sometimes “making software better” doesn’t enhance that value.