Agile Otter Blog

I started the new job at Industrial Logic. In addition to receiving online training from my peers here, I'm getting into the source code of our products (some cool stuff in there). Yesterday I got to exercise my google and stackoverflow skills as we dug into a windows-based product. My .NET work until now has been web, not native, so this was new territory for me and I had a great time. In addition, I'm getting involved in contract work here and strategy. It's only day 4, and I'm feeling like I'm really a part of the team. You would not believe how much we are in contact even as remotes. I probably talk to my coworkers ("boss" included) much more often than you cubicle-dwellers do. I still get think-time alone, but I'm getting to know and enjoy people pretty well. Enough of this, there's code waiting...

Your agile otter has joined Industrial Logic. We have so much in common that it didn't make sense not to join forces. I will be neck deep in products, courseware, metrics, and all of the other work that makes them so cool. This will be like chocolate and peanut butter, friends. I can't wait to join all my new best friends!

The latest Clean Coders video by Uncle Bob Martin covers Chapter 2 of the book Clean Code . This is a chapter that is near to my heart, since it bears my name and Uncle Bob even presents some flattering introductory material with a decidedly unflattering picture of me (all in good fun). The video is $12.00, but is quite well done and interesting. The less entertaining version which was the source for the well-edited version in Clean code is still available, and has examples in Python rather than Java. Bob's presentation has some thoughts not included in my paper (and which I endorse). The paper is not a replacement for watching Bob's zany and entertaining video but it can give you some of the same material while you ponder spending your hard-earned ten-spot-and-change.

With my last employer, we had noticed that our retrospectives were starting to lag in effectiveness and attendance. People felt like they were too busy delivering stories and solving problems to do anything substantial toward meeting retrospective goals. I knew that it wasn't the kind of company that would accept stalled improvement, yet developers were instinctively afraid to invest time. To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups: If it is free, just do it. There is no reason to delay implementing some changes, including (but not limited to): posting a graph, composing a "top-ten" list, swapping pairs more often, trying pomodoro technique, changing how stand-up meetings are performed, making better use of QA, tech writing, or Customer resources instituting changes to coding standard There is no reason to delay this kind of work. The CIO told us he considered it our job to ...

Here is the table from Agile And Beyond last weekend. There are a few interesting features here. You can see the cool phones, the notebooks, the Agile In A Flash cards being shared on the table, and to the left of the diet coke is an Agile Otter business card. I attended only two talks, and spent the rest of the time hanging out with my peers and having fun. The two talks were Mary Poppendieck's talk about where she sees post-agile going (a nice talk, btw, well given) and Dr. Michael Norton (docondev's) talk about technical debt. I was ill-rested, over-caffeinated, and a little eager. I had motormouth, but it was still a great time )for me). I hope that Mike Hill, Tracy and Angela Harms, Matthew Weitzel, Patrick Wilson-Welsh, Michael Norton, Zachary Spencer, Nayan Hajratwala, Matt Barcomb, Jon Stahl, Bill Tozier, and all the rest (drop me a note if I forgot to mention you) all had as much fun as I did. Best wishes to my colleagues on the other side of the lake!

Let's begin with this simple assertion: command.com sucks. It has always sucked, and always will. Powershell might be nicer, but most people haven't learned how to use it, and it's only available in one operating system anyway. If I say "command line" to a Windows-only person, they're thinking "command.com." Avoiding that command line is a huge part of making their lives pleasant. I am not slamming on hating the windows command line. All of us Unix/Linux geeks hate it too. I never feel much less productive than when I'm in command.com. I avoid it too. I started back when CP/M was the killer operating system. Its command line was not so great either, but it had a strong free software community who shipped programs to each other on floppy disks. As a result, we had this language called "submit" (and later "supersub") which you could actually do stuff in. It was like a real language. The command line suddenly was pretty dec...

I started teaching my youngest son python years ago. I started him with the turtle package and he drew circles, lines, and squares. He had a great time doing things like creating variables that carry his brother's name and setting them equal to "llama butt." Now he's older, and wanting to do some more programming. We decided to start with a simple guessing game, and picked "battleship." I also decided that he's old enough to get a handle on tests and classes. Tonight we decided what the rules were, and wrote some tests for creating ships and blowing them up. We'll be revisiting the stuff we've done, but by watching me and copying the text I typed he was able to run the tests a few dozen times, create a class, and start dealing with syntax and logic errors. It's just a start. We'll have to get into it more deeply before we'll know if he really likes it, but I'll keep you posted.

I want to take four teams of four people and arrange them in groups. Each group gets an identical book of crossword puzzles (or maybe a web printed book of a dozen puzzles of varying difficulty). The first group divides the book in four pieces and each member does 1/4 of the book. The second group takes one page at a time. The first guy does as much as he can and passes it to the second, and so on. The third group divides the book in half parts and solves puzzles as pairs. The fourth group has no rules about how to divide and organize the work. We would count finished puzzles once per minute per team. We would let the experiment continue until one of the teams finishes its set of puzzles. Publish the findings, and publish notes on how each team *felt* about their work style, and what they think they would do differently. That's it. I would like to see how it comes out. If you have the time and enough people to try this, please follow-up with a comment here to tell me ho...

Today we stepped it up a bit. Jeff Langr and I worked on our little project (shhh! it's a secret) and spent much of the day in django learning to test things. It cured a number of my developers' diseases and we got a bit done. We started out trying to use Lettuce, which is a good idea and worth improving. We got a couple of tests working, using the client to send get results from the server and BeautifulSoup to parse the returned html. It was mostly a good experience, but then we found out that our handlers weren't specific to the scenario or the feature or even the file or directory. If you register a 'before' it's 'before' everything (it seems). Still we got some experience with it, and I think it'a great idea. With some scoping rules attached it would be totally awesome for ATDD, and I dig that it's pure python so you don't have to have a bunch of different languages & tools to do the work. It's a good start. We picked up with...

I got too big for my britches last week and was feeling kinda saucy. I figured that having read a tutorial some time ago should be enough for a smart guy like me, so I started up a web project and an app and slammed in some model work, splashed an url on, and was thinking I knew what i was doing. No tests, but heck it's only a few lines of code and some generated stuff. Then the test thing got to me. I started searching to see some testing tools, and ended up reading three paragraphs of every tool tutorial I could find. I pulled down a few testing tools. I started writing a test, and before I could really evaluate whether I liked how it was going started to mix different test libraries together. Pull the html parsing from here, the basic test setup from there, the helper routines from another place and pretty soon... Pretty soon I realized that I wasn't learning anymore. I was permuting and chasing error messages and flailing and feeling kind of frustrated and lost. Today...

Our Card Of The Week from AgileInAFlash is #41 The original article is at the Agile In A Flash blog , and has slightly different wording. We adopted the phrasing from c2.com's page . I was pretty jazzed about having this card in our project, because it really does capture almost all of the code values and most design principles all in four little rules. It has always been profound in its simplicity. I wish we were able to make all of our cards and articles as concise and deeply applicable. My idea of a great teaching program would be to start with this card, a testing library, and a programming language. We would do some exercises following these rules. After doing some projects to get our testing and refactoring skills up to par, I would bring in the four big ideas one at a time, so we could see how to better focus our work. Then probably I would bring in the seven code virtues and SOLID . Then we would call it "a good start" and I would go home. The class coul...