Agile Otter Blog

I'm working in multiple tools and languages lately. It set me to thinking about what makes one better or worse than another. About the same time, I see a lot of mentions of yak-shaving hassles and OS reboots on twitter. I hear a lot of complaints about one feature or another of an ide, editor, or operating system and how they impede programmers from making software. We advise people to stop measuring "agility" in agile orgs and try measuring whether you have a better flow of useful, high-quality software. In the same vein perhaps we should measure tools by whether they get things done rather than by counting features and corporate supporters. Are we getting more done? A tool can be described as "productive" if it avoids adding obstruction to your workflow. If I want to do something, I am either allowed to do it easily (transparent tools) or I am impeded from doing it (unproductive tools). If I have to switch languages and contexts several times (as with java e...

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. Update We closed on the house on Dec 17, and have been moving over the holidays. There have been surprises and dis...

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

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.

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