Code-itis Interrupted

Let's talk about the so-called 'zone', that angelic place of unbelievable productivity. First, a quiz.

Questions for coders:
How best to get into the zone?
What brings you out of the zone?
Can two people be in the same zone?
How can you work in a group with the least disruption of the zone?
Is it possible to communicate your progress / status without leaving the zone?
Have you ever experienced the zone? Never?

Questions for managers:
How to encourage your coders to get into their zone?
How to keep your coders in the zone?
How to keep your coders from leaving the zone?
How do you keep personality issues from disrupting the zone?
How do you get a status report from those in the zone without disrupting the zone?

Most important of all:
Do you believe in the zone?
Do you have to?

So, people should work in the same patterns that you do because that is what you understand? Is it possible that other people work in different patterns? What is more important, people following your pattern or getting the code out in time, to spec, and tested? Can you work with or manage something you don't understand? This is a topic for later discussion. Eventually I'll put together a 'Psychology of Programming' series but first I'll probably read the book of the same title.

I know it is a bad habit of mine but when I think about it, the book 'Ship It' seems to be addressing many of these points. They are operating under the assumption that the 'zone' is real and show ways to take advantage of it without the reader even needing to accept the premise, just like you can take advantage of radio waves without ever taking a physics class.

Any thoughts, questions, rants?

The Age of the Design Review

Is programming an art or a science? That question has been asked for many decades and it will probably be asked for many decades to come. We've been searching for the construction equivalent of standardized parts like screws, nuts, bolts with which to construct software. We've treated coding languages and code libraries like silver-bullets and have been disappointed every time.

My question, is Software Engineering showing signs of maturity? In a post named "Leaky Abstractions and the Last Responsible Moment for Design" Jeremy Miller gives a good example of looking at a design and reviewing it.

I believe that we are seeing the beginnings of the common language needed to really improve the ability of practitioners to objectively discuss, evaluate, and correct the designs of others. One solution that is often suggested is to perform code reviews, which assumes that code standards have been put in place. Code reviews are nice but they usually come in two flavors, either examining the syntax or the design. Syntax reviews can be simple 'proper use of braces' to more detailed like patterns for using virtual destructors. There is a limit to syntax reviews because the code has already been written, like shutting the barn door after the horse has already escaped. What is frequently mentioned is the need for a design review which has been the holy grail. How do you do that without a common language? Design reviews no longer seem beyond our grasp. I've seen plenty of stories where time after time, software injuries are self-inflicted by Code Monkeys and Cowboy Programmers. Design reviews might not create world peace or feed the hungry but it might make it easier to keep apprentices or journeymen from masquerading as master craftsmen.

Between Anti-Patterns, Code Smells, and Refactorings I have the impression that the industry is reaching a point where we have the tools to properly review and critique software designs consistently. A common set of terms for describing and understanding problems; a common set of tools for describing and implementing solutions.

The Compost Heap theory of development

I've read about the 'Broken Window' theory of software development. Can we combine that with Code Smells and change the name of the theory to the "Compost Heap" Theory?

The image that comes to mind is a line of apprentice coders each with a basket of code snippets. Think grass clippings. Each one doesn't look that bad and smells like a freshly mowed lawn. As they arrive at the head of the line, they dump their snippets on a pile they all call "The App". After all the apprentices have emptied their baskets, 'The App' is covered and declared finished. After rain, heat, and much neglect, the neighbors start wondering what is producing that noxious odor. "The App" has become a compost heap. Imagine all the code bugs that thrive in that environment. I'd go on but that story is for another time.

So, the next time you come across a bad smell in your app consider whether your code is still pristine like you remember when you laid down the first few lines or is it a decomposing heap of trimmings. When you mow a lawn, the trimmings can be helpful, but only if they are spread out evenly. You can put the clippings in a big pile, forget about it, leave it at the mercy of the elements but what you can't do is plead innocence or even ignorance when the odor starts to make your eyes water. That smell you are trying to disown is the smell of code rotting its way into becoming code compost. Maybe not today, maybe not tomorrow, or even the next day, but sooner or later someone will have to work with the remnants. They'll ask themselves, "Who wrote this mess and what were they thinking?"

Don't let this happen to you. Clean up those code smells while they are small so it will be more like cleaning up after a puppy who is still young enough to be cute. A chore but one you don't mind doing. If you wait, it will get worse, much more like cleaning up after an overweight, incontinent great dane with bowel issues. High in volume and grossness, low in fun.

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)?