Pauses

An astute reader might notice that all my blogs are currently languishing. There are reasons for this, from my father's massive stroke to my continually-delayed house closing, to other crises in my family (biological and ecclesiastic) that have my attention though there is little I can do about any of these things.

Who knew that doing nothing and having nothing doable would be so taxing? That instead of neatly compartmentalizing things away as "to do later" and moving on, that one would be sapped of passion for work and learning and communicating? Still, this is how things are right now. As we move into Christmas time and the new year, I have little to advise in the way of agile practice and code cleaning right now.

On the other side of the bright and shining holidays and the various crises, I hope to have more to give you. I thank you for your patience.

A Waste Of Vertical Space

I'm getting really frustrated with code that pointlessly burns vertical space when I'm reading in a window in an IDE (in this case a C# type of IDE). I need to take in ideas at a glance as I survey this code, but people seem to not appreciate the "at a glance" qualities I treasure.

To wit: Do we really need 18 lines for each of the delegate's exposed properties?

       /// <summary>
       ///
       /// </summary>
       /// <returns></returns>
     
       public string GetSomeValue() {
           return delegate.GetSomeValue();
       }

       /// <summary>
       ///
       /// </summary>
       /// <param name="value"></param>
     
       public void SetSomeValue(string value) {
           delegate.SetSomeValue(value);
       }

Each three-line statement has 8 lines of worthless comment and unnecessary vertical white space around it.

I won't argue one way or the other about the need for parallel hierarchies of exposed classes delegating to hidden classes here. I've even left off the fact that there is gratuitous context being used in the real code (I've cleaned this up for your convenience). Ignoring all the other bits of silliness or grand architectural idealism, let's just talk about this very small bit of code.

Why not use this:

     public string SomeValue {
             get { return delegate.GetSomeValue(); }
             set { delegate.SetSomeValue(value); }
     }

I think we gain readability by deleting 15 lines of fluff and reducing the namespace pollution by half. The operations group more naturally, so I don't have to remember to mentally group getters and setters. I know that they're going to (and coming from) the same place. And best yet, that little snippet fits in my paltry IDE window.

Spreading a small bit of code out over a large area seems like rude behavior to me.

Okay, I've ranted. Thanks for the time. I'm back to the code.

Tech Upgrades for The New Year

I am replacing my old, dying laptop with a NoteBook (ASUS Eee PC 1005MA) but that's not what I'm talking about here.

I need to upgrade my tech *skills*. It is time for me to go waist-deep into the air, flash, javascript world. I need to get some skills with making hot web sites and making them look hot. Oh, there is more basic training needed in color and design, but I want to be able to do the technical side of it for now.

I'm going to dive in with a project, I think. Django behind, javascript up front. Then I need to look at air, flex, etc. This could be the year that I make my work more visible.

It will be fun learning to test-drive (or learning how to cope with not test-driving) these new languages and getting into the mindset of this whole trial-and-error UI world. But it should be exciting, and now that I've declared it on my blog I have to make it happen.

Watch this space.

Gratuitous Context

I have been working on code that oscillates between cryptic abbreviations and absurdly long names in functions. Sadly, I cannot reproduce it here for you, or I would. The problems with cryptic abbreviations I have hammered before, so my opinion is well-known (stp bng stngy nd us sm stnkng' vwls, k?). I don't talk enough about gratuitous context.

A name needs to be meaningful in context. The context of a class includes its namespace, the context of a method or class variable includes its class, the context of a method argument includes its method name, and the context of a local variable includes the method that encloses it. This context is cumulative as you navigate namespaces to classes to methods to method inners.

One thing that really is annoying is to see Grouping.Group.MakeGroup(string GroupName) with local variables that all include the prefix "Group". This is gratuitous context. This kind of naming actually hurts the readability of a program.

In a previous article I mentioned three concerns that will affect naming. In this case, we see that a local variable will be close to its point of declaration, and that there are very few variables in play. In this context, all the names are used fairly frequently and never outside of the method. All of these forces drive us to small, easily-recognized names.

Sticking the word "group" on the front of every name not only is unnecessary, it causes the eye to search farther into each word to tell the variables apart. While this is hardly a strenuous effort, it is enough of an effort to cause the reader to exercise extra care in reading instead of taking in the code in a glance.

The contextual prefix also means that the auto-completion of your editor/ide/whatever will pop up a list of names and yours is unlikely to be the first candidate. With a list of similar names, you must exercise additional care to be sure you do not accidentally pick the wrong variable from the list. This is becoming a fairly common type of programming error these days. Usually a pair programming partner will be able to tell that you have picked the wrong variable even if you do not notice it yourself, but this is again wasted effort.

In naming, a long name is not automatically better than a short name. Clarity is the goal. Sometimes longer names are harder to differentiate, which makes them less clear than shorter names, and a long bad name is worse than a short bad name.

For more on this topic, please see Chapter 2 of Clean Code, or the less polished version at my older blog and/or the earlier article the Long and Short of Naming.

Factors Driving Naming

As I lay awake in bed after about 4 hours of sleep, it suddenly dawned on me that we've not given enough thought to why we need good names and when we need good names. My blanket statement of position is strong enough: code that is hard/slow to understand is hard/slow to change reliably. When we use better (not just longer) names, we find our code can be easier for others to understand.

We can vet our naming system by pair programming. If we and our partners cannot devise a way to make the code more readable, then it is probably readable enough for now. By using TDD we can create executable specifications that further explain why the code might have an odd turn or surprising detail. Further, when a complex problem has a simple and generic solution, the tests show that we've covered all the bases (or that we haven't). Between the clear and obvious tests and the clear and obvious code we can largely eliminate the need for comments and frequent vertical line breaks and flowerboxes. Code + Test can be clear enough.

There seem to be three factors that drive the need for clarity in naming.

• Distance from declaration. We approximate this with "scope". An iteration variable in a list comprehension is created and used all in one expression, and need not carry the context that would be needed for a class name from a distant package/namespace or (God forbid!) a global boolean variable. We need to contextualize things that will be used far from their point of declaration. Things used near declaration/initialization need not carry as much context via naming.


• Number of names that are "in play" in a given routine will drive the need to create clear distinctions between the objects they name. In a method like Math.Min(int x, int y) there is not much we need to know about x and y. They are just two ints, and we want to know which is lesser. But if we have a function that is manipulating 11 variables in 4 lines then we start to have a problem with variable density. People with particularly strong math skills don't feel the need as much because they learned earlier to deal with extremely economical notation, but that knack is more a rite of passage than a readability ideal to be propagated. In a name-crowded space, it is simply harder to differentiate one thing from another and people may type 'r' meaning 'k'. As my colleague Vadim points out, it is more important here to have an easy visual distinction between names (something overly long names may hurt more than help).


• Infrequency of use drives to longer names. The less a name is used in any given context, the more it must describe its own purpose. Conversely, a name that is used repeatedly in many contexts becomes familiar to developers, and having a long name merely makes it tedious to read and easier to confuse with similar long names.

I have long approximated these issues with a rule (from James Grenning, I think) that the length of a name should be in direct proportion to its scope. My colleague Vadim has challenged the simple rule but I was not really ready to think past it until a recent amicable disagreement with Bob Martin on naming, followed by a serendipitous period of activity-free nocturnal wakefulness.

Now I think I'm seeing naming as trade-offs between these forces. As always, I am interested in counterpoint and comment.

Code That Makes You Feel Good

There are clever code constructs in the world. Some of them are quite useful in the right circumstances. Some, like Duff's device or the Curiously Recurring Template Pattern might prompt a double-take or some serious study to comprehend. Some are are even simpler to understand, like the Visitor design pattern, yet puzzling them out and making an implementation that actually works releases some endorphins. You feel accomplished for working through a difficult code device. Actually having N-levels of nested lambdas feels like the work of a wizard when it actually works and gives a result you are looking for. Clever and inobvious operator overloading can make some weird code work, and make you feel pretty good. A bizarre bit of code can feel like a real accomplishment. I was listening to a Stack Overflow broadcast a while back and heard one of the participants praising an obscure code trick as being "elegant", while the other corrected him that it was a kind of a hack.

Dirty tricks may stretch your brain in new ways and teach you things you would not otherwise have learned about your programming language or environment. Learning strange devices and code patterns can open you mind to new ways of thinking about software. These puzzles rightfully make you feel good about your growing skills. That "eureka!" endorphin rush is prized by mental athletes and rightfully so.

I've built things that made me feel proud for the wrong reasons.

Being "clever" is not strictly a bad thing. Being someone who loves code means loving a good puzzle. The problem is that the rush of figuring out or implementing puzzle-based code feels like an accomplishment and a triumph, when in reality it may be opulent self-indulgence.

Certainly there is plenty of code in the world that suffers more from a lack of brilliance, being unintentionally (even unknowingly) stuffed to the brim with implementation complexity. Programming stupidly tends to produce more code than necessary, and more complicated code as one kludge covers for the deficiencies of another kludge and the patches pile up on each other. Not thinking about the code, not learning to write code that is efficient in effect and parsimonious in quantity, not considering side-effects and weaknesses, not programming *well* is a horrible thing. We are told that 80% of all people believe that their work is "above average." That means nearly 40% of us are wrong about our work, and also not in a place to even recognize it. We all need to learn more about this crazy trade.

Yet the vast bulk of code is more workaday stuff, and would benefit more from from clarity and simplicity than from ego-stroking brilliance. We don't need very many Duff's Device implementations or clever metaclass madness or obscene table-based subsystems that totally obscure the flow of a program with levels of indirection through void pointers. There are things that we *can* do but should not do, and yet these things feel like implementation triumph. We put them together, and by golly they actually work! They may even be performant, yet even our better coworkers are loath to maintain the code.

The problem is not that we need to dumb-down the code. The problem is that we need to simple-up the code. If we can turn our mental resources to find ways to eliminate opulence and duplication and create more amazingly simple code, we can eventually get a reputation for writing code that attracts our coworkers and fluidly accepts change. That beats a reputation for writing obscure, difficult, and fancy code any day.

My dream is that my coworkers will see code I've worked on and breathe a sigh of relief. "Oh," they'll say, "it's Ottinger code. No problem." This echoes Ward Cunningham's comment to Uncle Bob (quoted in Clean Code), that truly clean code does pretty much what you expect it to do.

I think that Abraham Lincoln's stated goal is still a worthy pursuit for the software professional.

Sorry Way to do Business

I have been thinking a lot about Esther Derby's work on performance assessments and wanted to jot this down.

Competition is a good thing when it pushes people forward, but anyone who has ever played Sorry can tell you that the game is in is the relative progress you make with respect to others on the board. You can succeed by getting better movement cards than other people (being lucky) or by denying success to the other players (opportunistic sabotage). If you can block forward progress and send people back to the start then you have a little more control of the game board. The trick becomes making sure you can move between safe spaces without sacrificing too many pieces while wiping out the opponents from behind.

Relative success in a company is, I think, intended to be reached by propelling yourself forward. What I have seen in my 30+ working years is that you can also move ahead more surely by hopping between "safe spaces" and denying success to your coworkers. I've seen people who were excellent at that game. They take a larger slice of a smaller pie, which affords them the prestige and perks of a winner.

But it's a smaller pie they're making. Denying success to your coworkers should be an absolute obscenity inside a business. To consider the company achieving less so that you can beat that other salesman, manager, etc. to the perks is without merit. People who play this game are Sorry coworkers.

Now, the problem with it is that a Sorry boss will look for the Sorry workers, and will admire those "smart enough" to play this Sorry game well. He will admire the sharper gamesman and will not mind promoting him... to a point. Eventually the Sorry employee will start denying success to his Sorry boss, once he has some contacts higher in the Sorry company.

Don't work for a Sorry company. Loving your job means never having to say you're sorry for working there.