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.