Agile Otter Blog

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 previo...

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...

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....

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...

One question for you: What if someone told you that you were going to have to serve chicken less well-done in order to make it through the lunch rush? Let's say you are working in a fast-food restaurant that is attempting to keep up with Chick-Fil-A and KFC and Brown's Fried Chicken. Speed and quality are important, but you are a fast food drive-up, so the audience is a little forgiving. Now you find out that the other local drive-up chicken joints are selling more chicken than you are on Sundays. The management suspect the product is not being prepared fast enough. They remind you that quality is important, but sometimes you just have to ship the product if you want to compete, no? You are only the fry cook. Your manager makes three times as much as you do, drives a much nicer class of car, dresses better, probably has more years of management experience than you have fry cook experience. He probably knows what he's talking about, and he can certainly fire you even if he d...

I was invited out to breakfast with a good friend who works in HR. Between sips of coffee and bites of Tabasco-soaked potatoes, Tom mentioned that he has been to leadership seminars that spent a lot of time on fuzzy ideas like "finding the hidden leader inside yourself" but even give a definition of "leadership". That took us in a new direction. I realized that in making up my list of the qualities of a good leader, I didn't even consider the definition of leadership. This week in Twitter, @marick brought up questions about the meaning and nature of leadership also. Now I can't escape the meme rattling around in the back of my head. It's a bit like when you have three bars of a song in your head and it won't stop repeating until you hear the song in its entirety. What is leadership? It is clearly a kind of skillfulness, but what skill is it? What set of skills define leadership? My short list of "attributes of a good leader" was e...

The Background I (re)tell a story frequently about a place I worked in the 90s. There was a piece of code with an absurd cyclomatic complexity score, running literally hundreds of lines in length, and being called from myriad places in the code base. The code was written to check to see if two ranges were overlapping. Being written in a poor 4GL, it took four parameters representing the starting and stopping dates of two time ranges. Such a simple task for the code to be so horrible and lengthy. In C it would look rather like this: bool ranges_are_overlapping(int a, int b, int c, int d){ } It quickly became clear to the most casual reader that the ranges were a..b and c..d. Well, sort of. The code was defensive and was written with the understanding that the range-defining arguments could be somewhat unordered: if ( (a<b) && (c<d) ) { // blah blah } else if ( (a==b) && (c<d) ){ // blah blah } else if ( (a>b) && (c<d) ){ ...