The 'Exceptional' Programmer

My wife showed me some code she was reviewing for the system she supports which was not working. She had been looking for where the problem was located. Obligitory dumb question: Didn't it have error messages? Of course it did! But if the error message isn't correct, you can easily end up on a wild goose chase. In medicine they call it 'treating the symptoms' when they know something is wrong but can't find the root cause. In this case, she had found a problem with the error handling code. Don't get on my case about proper syntax, this is just an illustration of the C code she was reviewing.

errCode = findError();
sprintf(errorMsgBuffer, "There was an error. ", errCode);

errCode contains the actual error message encountered and errorMsgBuffer is what is used to output the message. How quickly can you spot the error? Did you find it already? Well, too bad. I'll tell you anyway. The error message in the sprintf is missing "%s" so the errCode never gets copied into errorMsgBuffer. Simple fix, what's with all the fuss, right? Well, if exception (or error) handling is so important, why do we keep finding the same mistakes over and over. If this was tested, it escaped notice or was intentially ignored. I don't know which was the case for the code in question but it had indeed made it to production.

For you Exception bigots out there, here is an equivelently heinous bug, Exception Hiding.

try{ foo();}
catch(Exception e)
{
throw new Exception("There was an error");
}

How is anyone supposed to know about the original exception when all the information is tossed aside? This is bad code smell of garbage dump proportions. A better question is why this isn't caught in code reviews. When I started searching for this anti-pattern it was easy to get Eclipse to find where exceptions were being constructed. If there was an exception class constructed inside a throw clause it was instantly suspect. There are reasons when you want to create a new exception in a catch() block but those situations are, well, the exception rather than the rule. I need to get a copy of Anti-Patterns but this might be a good candidate if it isn't already. I'll call it Exception Upchuck. The code is sick. Swallowing an uncooked exception but not purging itself of the problem. Instead, it is vomiting back a new problem and making it that much harder for the code doctor to diagnose.

*Update: constructing an exception in a catch block is not always a bug but should at least invite review.

Just Flailing Away

You're back? I'd better be careful. If more people start showing up to these group therapy sessions, they might start charging admission. That would clear out this place and I'd be able to go back to tilting at windmills. Tempting...

I was just thinking (I know I know, *slaps hand*, stop that!) about training someone to be a good developer. The accepted mantra is always, "Send them to training". But even when training is available, it always seems to be too early or too late. Have I ever told you about my friend Jack? I have? I'll act like I didn't hear that. Jack is a developer at a large company. They embrace new technology the way someone lost in a desert for days embraces a cactus; so thirsty it is easy to rationalize, "It won't hurt that much and I'm really thirsty and want a drink right now!" They can quench their thirst but its a prickly proposition. Anyway, Jack was telling me about getting training at work. Ok, he was ranting to beat the band but I don't want you to think he's crazy, that's reserved for me. Jack gets put on this cutting-edge project using new technology on a new platform developed with new tools. So Jack gets sent to training and then doesn't get to use it for months.

[From the back row]:*boo!*, *hiss!*
What are you griping about, you get what you paid for. If you want good comedy, go somewhere that'll demand some lucre. I'm just here to hear myself talk. The jokes are free, just like admission.

So back to Jack. Jack's training showed him all the bells and whistles. You know the drill. How to save a file: "If you want to save a file, hit the [Save] button!" or how to color your text, "This button will turn all your text blue!" More 'how's than a tribe of Native Americans in a marathon of bad spaghetti westerns. I've always preferred my learning to be more about 'why' (Pardon my French) than 'how'. A book or on-line tutorial and show me 'how'. My search for ones that can tell me 'why' (Sorry, about that) sometimes makes me feel like I'm panning for gold and only finding fools-gold. Finding such a rare breed "Look, she can clearly explain why I would want my text blue!" (Excuse me! I must have a rude tic or something.) can feel like finding that one gold nugget that makes it all worthwhile.

Even when Jack came back from training, whenever he'd try to apply what he learned, if it slowed anyone down or required them to change how they worked, he'd be met with "We don't have time to learn how to use that fancy new tool! Just do it the way we've always done it."
Hearing that story, I couldn't help but imagine how that would work in real-life. Imagine your hometown city pool (Hey, we're imagining here! I don't care if your city was too poor to have a pool.) where you went to high school, complete with life-guards, deep end, diving board and lots of squealing kids among other things. You get a job there as a life-guard even though you can't swim. They tell you they'll provide the training. When you show up to work, no training. Your boss tells you not to worry, no one every drowns anyway. You take him at his word until the day the Senior Class President "Johnnie" shows his true colors and throws the class geek's kid brother, who also can't swim, into the pool. Jane, the head cheerleader, screams, "Johnnie! Don't you care that he can't swim?!?" To which Johnnie replies with a shrug and a disaffected scowl, "Nah! That's what life-guards are for." Ignoring his bad grammar, you realize that he means *you*! Jumping in, you flail your arms to keep afloat and manage to make your way over to the little geek where he grabs onto you with a death-grip. You keep from getting water-logged long enough to get back to the edge of the pool where everybody's safe and all is right with the world; until you run into your boss later. "What do you mean you want to go to swimming class?" with a tone that implies that it's your fault people need lifeguards that can swim. "We don't have time for you to learn how to swim." Blithely deflecting your eloquent recounting of the days incident, "It was a fluke, a million-to-one. Go back to work. What are you worried about anyway, everything worked out ok, right?" That night, when you go to bed your dreams are filled with flailing arms and water being flung everywhere and you wake up in a cold sweat. You feel thirsty but don't know why.

Wake up out there! The snoring is so loud someone might come and wonder what the commotion is all about. And no, the concession stand did not bribe me to tell that story.

So, what does that leave? The next time you want training (or want to apply training to real-work), remember Jack and his developer cohorts, struggling to keep their heads above water, their cubes like mini-pools, and they're all just flailing away.

Thomas Jefferson on Software

Thomas Jefferson on Software
Software Development lessons from our Founding Fathers

Who knew that Washington and Jefferson had experience with Software Development? When they were discussing the methods (methodology?) by which the people should be governed, they split the power that government can wield into three branches. In doing so, the founding fathers tapped into a very fundamental division of responsibility. By forcing each division, or branch, to work *with* the other branches sometimes and *against* at other times, they intended to balance the power of any one branch and work to check the abuse of power by all branches.

*From the back row* "What does that have to do with software? The man's gone daft!"
Hey, I'd give your money back but this is a free lecture.

Ok, maybe the civics lesson is boring so I'll summarize:

Legislative - Decides on and Defines law
Executive - Implements and enforces the law
Judicial - Interprets the law and decides whether the implementation follows the law as defined

It didn't take much of a stretch to come up with the following roles and responsibilities:

Customer - Decides on and Defines features
Developer - Implements requested feature
Tester - Interprets the feature, Decides whether the implementation follows the definition.

For those who just woke up, here are the Clif-Notes:
Legislative (Customer)
Executive (Developer)
Judicial (Tester)


Again from the back row: "If software development has three branches does that mean that it also has 'Checks and Balances'?"
I'm glad you asked that question! Of course it does, give that man a cigar! Let's use the tool we get all our information from, the idiot box.

*static*
[CLICK]
And now for a word from our sponser!
It's lah---og, it's lah---og,
It's brown! It's round! it's wood!
[CLICK]
*This is a story. *
*About a man named Brady.*
[CLICK]
"And now back to 'Jefferson on Software' on the History channel!"

...For simplicity's sake, I've come up with several scenarios to help describe how the different branches relate.

Checks and Balances


Feature Definition:
- Customer requests a feature

Scenario 1 (signs law)
- Developer accepts feature

Scenario 2 (veto)
- Developer vetoes a feature request(feasibility, priority, poor definition, not testable, etc.)
- Customer does not overrides the veto (low priority, nice-to-have)

Scenario 3 (override veto)
- Developer vetoes a feature request(feasibility, priority, etc.)
- Customer overrides the veto(raising the priority, accepting constraints, etc.)


Feature Development:

Scenario 1 (default)
- Developer implements feature
- Developer submits feature for testing
- Tester validates feature

Scenario 2 (improper implementation)
- Developer fails to implement and/or submit feature for testing
- Tester declares feature fails test by default
- Tester notifies Customer of incomplete feature

Scenario 3 (renegade implementation)
- Developer implements unwanted feature
- Tester decides not to include it in the application
- Customer cuts funding (power of the purse)

Feature Testing:

- Customer provides a testable feature request
- Developer agrees to the test definition
- Developer implements feature

Scenario 1 (feature passes test/upheld)
- Tester declares feature as working as requested

Scenario 2 (feature fails test/struck down)
- Tester declares feature as not working as requested
- Feature returned to developer for further work

Scenario 3 (feature passes test but Customer disagrees)
- Tester declares feature as working as requested
- Customer disagrees and thinks the feature is not complete
- Customer submits a refined new request with an updated feature definition (new legislation)


Without the Testing branch, there can be no checks and balances between what was requested and what was delivered. It is a peer to the other two and should not be seen as subservient.

For all those non-coders, pretend you are back in Speech 101 class. They teach you to tell them what you are about to say (state the requirement), say it (code the feature), then tell them what you just said (test the feature)?