Agile Otter Blog

Soon we'll be on the other side of Christmas and starting a new year. How about for the first week of January we try doing without copy-and-edit programming. What would happen if we were to write code off the top of our heads? Don't just hand-type the example code you would have copied anyway, but try writing it as if the code you really wanted already existed .  How would you have liked to initialize that class? When you are writing a test, do the order of the parameters of that method make sense? Are you doing three- or four- or five-step operations that ought to be their own function? Is the method you need a member of the object where you would expect to find it? You can't find out by doing copy-and-edit programming. Let's all try the grand experiment of not copying ANYTHING for the first work week of January. What could it teach us? What could it hurt? The hashtag will be #freshstartweek. See you there.

Single-entry, single-exit programming was a great breakthrough that led to a serious improvement in the lives of many programmers. In the jurassic period of software development, anyway. In the modern era, among good programmers, I think that single-exit is an example of the many once-best practices that outlive their usefulness. Method length and nesting are our primary enemies. Multiple returns in nested, long methods turn trouble into disaster for the poor developer who has to understand and debug a routine, not to mention the guy who lost the coin toss and has to actually modify it.  Once code is bad, multiple returns makes it far worse. Start with pure function length: In a 500-line function two returns is dangerous, and five would be maddening. Drop to 50 lines, and it's still pretty daunting. Drop to 10 lines, and the risk of missing a return or misunderstanding the method is slight. At 5 lines, there's no hint of the problem that single-exit solves. Switch to nes...

As you head into year-end appraisals, here are a few resources for you. Time for the Annual Performance Review Supporting Team-Based Work Addressing The Most Common Concerns Building Feedback Into The System Notes From Peter Scholtes A Perspective from Vanguard Note: most of you employees do want time with their bosses, they just don't want a once-a-year backward-looking judgement. They'd rather the boss was a part of their team and gave forward-looking direction all of the time. More feedback is better than less, and more engagement too.  For some other pointers, see: Management Theater The Four Ts.