Agile Otter Blog

I've had enough questions and references to this that I need to explain this odd effect with the fashionably Asian-sounding name, which is being mentioned in boardrooms and team rooms all around the earth today. It's not from any Asian language. It is "poo" (such as you might unhappily find on your lawn), and "shoe" which you might happily purchase for your feet. The poo-shoe effect is when you stepped in something, and it stuck to you so that you will have to work long and hard to rid yourself of the stink of it. Now, this doesn't refer to bad choices or acts of temper or moments of ill-will or malfeasance that will be remembered. That is simply "bad reputation" and is a component of social justice. That's not worthy of being considered an instance of the poo-shoe effect. Nor is it about the honest or unintentional kind of mistake or accident that can mar ones reputation "oh, yeah, he's the kid who peed his pants in third ...

There is a relationship between how slow tests are and how much we interact with the tests while we are developing software. If the tests run instantaneously, I'll run them constantly. If the tests run in 30 seconds, I will run them 3 times in any 5 minute window of coding. If they run in 1 minute, I will run them 3-4 times per hour. If they run in 10 minutes, I will run them maybe 3 times a day. If they run in an hour, I'll run them 5 times a week at most. If they run for a day, I will almost never run them. If the build/test cycle is not incredibly fast, I will not participate in the code as fully and richly, instead falling back to rely on my IQ and memory and good intentions more. This is why tools like Infinitest for Java, sniffer for Python, autotest for ruby, and the like matter so much. It is also why there have to be build servers and test servers for any significant project. It is also why manu...

TDD is a pretty simple system, as popularly described.  For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this: It's the right way to think about TDD, and the right way to get started. When you get to a real project in a team environment you have many other issues to consider.  In a modern team environment, with a DVCS, it looks more like this: Get the current code ( git pull , get clone , hg pull -u , whatever) Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages. If there are no tests, write a trivial failing test (" assertTrue(false) ") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test. Write one "real" red test. INSIST ON RED. Write code to turn it green. Local commit "save your game" Refactor (or intentionally choose not to). Check to...

Famously, scrum has used an old joke to explain two kinds of participants in development work. Pigs and chickens is a reference to having bacon and eggs for breakfast; the chicken is involved (donates an egg), but the pig is committed (gives his all).  In scrum, this translates to stakeholders (chickens) and material participants (pigs). It always seemed funny that people who are on the hook to pay for the work are chickens and those who are paid whether or not the product succeeds are pigs. Still, I appreciate calling out the idea of advisors and stakeholders v. material participants. I wonder sometimes about those roles for people who are not primary stakeholders, yet are somewhat involved in the development, but primarily act to give permission or to grant or withhold resources. Are those chickens with a pig complex? Pigs with chicken complex? Porklucken? Non-coding architects who must approve designs Sysadmin/IT who controls the team's computing resources Externa...

Our office firewall gets in the way of Yuuguu , probably by blocking UDP traffic I'm not sure what the real . Finally a coworker was WFH and we were able to try it. Hey, it worked. Lag wasn't bad, control wasn't hard to trade, and it didn't really get in the way. It really shared the other guy's screen, not just certain windows. That was very convenient, but it also meant that I could see his IM and email notifications and the like. If you worry about such things, be warned. OTOH, it means that he could pop up editors, SQL tools, log tail programs, and the like without having to explicitely share them with me as he as to do in webex. Yuuguu didn't include voice, but included a voice conference line. It does nice instant messaging and screen sharing, though. We skyped for voice, and yuuguu-ed for screen share. It can tie into your instant messaging accounts, which makes it easier to find people you know. We had work to do, so we didn't spend so much...