Agile Otter Blog

Sometimes this world gives me joy. I take photos as I travel. I also try to take some time to see the world and take extra photos.  One day I realized that I could set my Mac to use random photos for the backgrounds. It seemed natural to create a folder called "backgrounds" on dropbox and use it. Over time I've moved a number of travel photos to that folder. Today, as I was working I realized that my home office's three screens were showing NYC's Central Park, the view of Edinburgh from Arthur's Seat, and Colorado's Garden of the Gods.  As I was typing this, it changed to three more photos -- the pond in Central Park, a different view of Garden of the Gods, and the beautiful white cliffs of Dover in the UK overlooking the channel. Through the day, when the backgrounds are not covered up in browser tabs, code editors, terminal windows, and social media apps, I can see my past adventures reflected in beautiful high-def. I remember how much I lov...

This is a slightly-edited re-presentation of a thread in Twitter.  Original post Unrolled post As twitter is ephemeral, and blogs are longer-lasting (and easy to point to in the future), I have copied it here and fixed a couple of typos that twitter wouldn't let me correct. Once upon a time, people argued that TDD is impossible. You can't write a test first, obviously, because you can't test something that doesn't exist. It's obviously ludicrous. But you change how you think about "a test" and it works just fine. Likewise, two people working at one machine? Ludicrous! That's twice the cost! Except that when you realize that programming is more about thinking than typing it makes easy sense. It works just fine. And mobbing! Why, how stupid must that be!!!! Having five or six people work on one task is horribly wasteful... until you learn that it gets work done quickly by putting the right number of brains and set of skills on the task. ...

The predictability of a team is subject to the predictability of the work . Duration of a task depends on three things primarily: Raw effort -- fairly predictable, measurable, repeatable -- easy stuff. Risk -- chance we might break something and have rework or damage; VERY hard to predict in advance of efforts, extremely hard to detect without significant effort in automated testing AND exploratory testing. This can bring us late delays that cannot be ignored.  Uncertainty -- the amount and difficulty of the learning we will do, along with the chance that we may hit dead ends and have to start over. Cursedly hard to predict even order of magnitude. Interesting and Uninteresting Work Work that is mostly raw typing effort is uninteresting. Nothing is learned there, nothing is innovated, nothing taxes or stretches the workers. It is a rare situation in software work because developers have a tendency to automate any uninteresting work. Not only does it save them a...

WARNING: the blogger "WYSIWYG" editor is really not very good about the "WYSIWYG" bit... so this article looks great in the editor but is a real crapshow in the actual post. I'm fixing it. Be kind, and bear with me. In our eLearning , we publish problems and solutions. Sometimes people contribute other solutions and we show those as well. Today's sample comes from our Test-Driven Development album. Geepaw hill tells us "everything matters" -- so today I'm going to nitpick at something that (in this case) is tiny and you might consider it insignificant. So be it. But just the same, I would like to introduce you to a process that can improve your code and design in ways subtle and profound. In this case, it stays a little to the subtle side, but that's okay for a blog. Here is a source code example: AreEqualWithPrecision(PhoneBill.calculateRate(PhoneBill.GOLD, 900, 1), 49.95); AreEqualWithPrecision(PhoneBill.calculateRate(P...

I came across an interesting article the other day, stating: EXPECTATION – OBSERVATION = FRUSTRATION I think this is really good. However, I think there should be more emphasis on spoken v. unspoken expectations, and then on agreements instead of expectations.  Also, the refusal to adjust expectations out of compassion and respect for others is poison. via GIPHY And yet, people are quick to judge the behavior of others rather than to approach surprises with curiosity . A lot of disappointments don't need to be upsets.  People judging situations scream "this is wrong" instead of "how fascinating!" We refer to the difference between expectations and actual behaviors as a " curiosity space ." It is where most of our learning takes place. One of my friends described it as a "cache miss" which is helpful to readers who are engineers or software developers (or both).  So, here, to help us understand, is my quick guide...

I finally got around to watching Frozen . I don't have any small children of my own and wasn't really interested in it for my own viewing pleasure, so it took a long time. I didn't know the songs, didn't know the characters, didn't know the storyline. We were watching a friends' child last weekend, and the child really wanted to see Frozen, so we did. Overall, it's cute and has nice jokes and beautiful animation. I can tell they spent a lot of money on the soundtrack. I probably won't watch it again, being well outside of the target audience. There was one poignant moment that stood out to me, though.  Anna, the red-headed sister of magical-powered Elsa, came to retrieve her (very dangerous) sister and bring her back to their town. Elsa warned Anna that she needed to stay in her ice castle and couldn't return because she was a danger to everyone. Anna said: You don't have to protect me; I'm not afraid.  Boom. That line. Feeli...

I worked with a team where everyone was trying to do pair-programming, but it was too hard for them. I asked what made it so hard, and they told me it was simply so exhausting. They were slumping in their seats by 10:30 in the morning, and by mid-afternoon, their productivity had plummeted. I looked around the room to see if everyone had the same experience. They all nodded their heads. This was the big problem that was plaguing them. I asked them how they were doing the pairing. They were forming up in pairs, and working all morning straight through without break. They went to lunch, and after lunch rejoined their partner and worked until quitting time. They really were sticking with the pairing, and I had to admire their dedication. They were working so hard to try to build great software and working so hard at pairing that I was deeply touched. But here is the problem, too.  They were working too hard at it to be able to do it well. Biological Beings We are bio...