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.

Habit is powerful. Inhabitants of intersection set People who place symbolic value on the wasteful practice People who have built a reputation on the wasteful practice People who find the wasteful practice a pleasant diversion People who have failed to change it in the past, so they don’t want others to succeed People who feel that eliminating the practice would be “giving up” or “quitting” People who fear the change and disruption eliminating the wasteful practice may bring People opposed to it, but who base their practice on the assumption of it’s permanence People whose current role is based on continuing the wasteful practice People whose bosses are unwilling to eliminate the wasteful practice People who see it as a sign of rank or importance, and aspire to rise to it It is easy to imagine those on the far right or on the far left, but that middle set is surprising to find. 

Error-avoiding is overrated. Too often people want to wait surprisingly long periods of time before making a move, in fear that their move might be the wrong thing to do. The amount of fear and pre-thought we put into projects can be staggering. I'm not here to say that design and architecture and platform design aren't important. Clearly there is value to having a workable plan and a goal in sight.  However, the idea that you must be right on the first day of development flies in the face of all our experience with application development. You only need to be "right enough" at first, and able to correct as time goes on. We can become invested in concepts, ideas, development stacks, and architectures to the point that we forget that all up-front design decisions are just guesses. It's akin to a man walking up to the blackjack table with the intention to draw twice on the first hand and once on the second, even though those hands have not been dealt. The proble...

I'm back to hacking some python (fun stuff!) and have been noting some packages that every well-dressed virtualenv should have. I'm interested in knowing what you use, and for what. Essential packages I can hardly live without: bpython - because it's my favorite shell sniffer - because CT is the bomb, and sniffer works on mac (autonose not so much) mox - though I don't totally love it, I'm somewhat used to it now. May switch to something more context-manager-like. Task-specific stuff: BeautifulSoup - if I'm parsing stuff. I really like this library mechanize - if I'm writing tests on a web framework. Other than js weakness, it's quite nice feedparser - for rss stuff PIL - because image manipulation is no fun without it What do you feel a well-dressed virtualenv should wear this season?

Dear Mercurial, I don't love you (yet). This looks fine if you only spend a few minutes in the 2-3-2-3 loop. On the other hand, if you're in a very busy team and there are refactorings going on (and when shouldn't there be?) then you will want to have a loop from 3 to 1 pretty darned often (at LEAST a handful of times a day). At step 1, "For a while" should mean "if a couple of commits have been made by coworkers." The problem I have with mercurial is that the process of pull, merge, commit is too cumbersome. I have coworkers who swear by rebase, and others who have been bitten enough that they're scared to death to use rebase, and instead pile up the "merge" commits. There needs to be some kind of change made, if only to fix rebase, because this work flow is broken for active, productive, agile teams.