Agile Otter Blog

I simply hate #regions. Apparently I'm not alone. In C#, a bit of code surrounded in #region...#endregion markers is folded shut by any decent IDE. The code becomes invisible until you ask to see it. This sounds like a good idea, but it really is not. It makes code *look* smaller, but the code is not smaller. It is more of a girdle than a diet. The code is instead better-hidden, an attribute I can hardly describe as a virtue. There are plenty of reasons to hate long methods and long classes. The foremost is that you cannot see and grok them at a single glance. The programmer needs to read code quickly without misunderstanding it. The #region tag is one of the most sure-fire ways to make that problem considerably worse. The region worsens most of the problems long classes and long methods cause. The #region is almost certainly an American or British policy decision. It makes things seem better while all the time making them considerably worse. Whenever we prefer 'seeming...

If you cannot name something well, then please name it appallingly badly. No, this is not a joke about the iPad. When I am stuck for a name, the problem usually not my command of English or lack of a good Thesaurus. It is that either I don't know what kind of a thing I'm applying the name to, or it is in the midst of morphing from one kind of thing into another. In such cases, neither can my pair programming partner name it. Its identity is unclear. Yes, this is about the Single Responsibility Principle again. A class with a clear single responsibility (does it all, does it well, does it only) is easy to name. Anything with a responsibility that is not clear, not complete, or is mixed with other responsibilities is going to be hard to name. Anything that can't have a good name should have a bad name. A very bad name. Most of the rules still apply. You want something greppable, something that isn't going to disinform, and something that is pronounceable (etc). What ...

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