Agile Otter Blog

 (originally posted in march 2008, republished with edits) I read a mailing list entry in which one fellow (who? I can’t remember!) asked another: “Do you want to get better at what you’re doing, or find a better way to get the results you want?” I’m a sucker for a good one-liner. That one had me thinking, and as I’ve had other conversations about innovation, I keep coming back to that line. In many Agile practices, we work really hard for a week or two, and then hold a retrospective. The purpose of the retrospective is to find  ways to work more effectively for the next two weeks .  As we develop better software, we also evolve a better team. We may use “tricks” such as tracking our velocity and recording blockages on our ‘waste snake’ to provide data for our decisions, and we use gut feel to evaluate those things that feel like collateral effort to us. If the practice works, we will see incremental improvement in the team. We will develop ways of avoiding special variat...

  Originally Posted   on 2/26/2007 One of the more annoying problems in code, confounding readability and maintainability, frustrating test-writing, is that of the multidomain variable. I suppose somebody forgot to clue me in to the Great Variable Shortage that is coming. I have seen people recycling variables to mean different things at different times in the program or different states of the containing object. I’ve witnessed magic negative values in variables that normally would contain a count (sometimes as indicators that there is no count, much as a  NULL /nil/None would). I might be willing to tolerate this in programming languages where a null value is not present. Yet I have seen some code spring from multidomain variables that made the code rather less than obvious. I think that it can be a much worse problem than tuple madness. I have a rule that I stand by in OO and in database design, and that is that a variable should have a single, reasonable domain. It is ...