Agile Limerick 1

(not to be taken too literally.)

I got certified as a Scrum Master,
To make my projects go faster,
But the code was mess,
Never refactored, I guess,
So Agile, for us, was disaster.

Technical Reviews, More on Test Driven Design

Re-run from 2003.Mar.26 Wed


Scott's essay on TDD is up here and Ron Jeffries's critique is [gone]. I'll have more to say about it after reading it a couple of times.

That recent issue of STQE Magazine also has a great short essay by Jerry Weinberg on technical reviews being a learning accelerator. One thing I want to point out is that junior programmers should be reviewing the work of master programmers, not necessarily to find errors, but to learn from the master - and of course, master programmers can make mistakes too, which are often visible to junior programmers as well as other master programmers. If the master programmer is humble, he/she can learn from a junior programmer, too.

I've been reading Weinberg and Freedman's book on the subject of technical reviews Handbook of Walkthroughs, Inspections and Technical Reviews  (which was written in FAQ style - question/answer), and was a bit surprised by their recommendation that when people are being trained on how to technical (code) reviews, they should have some practice at conducting a review in the presence of hidden agendas.

Some examples of hidden agendas in code reviews: person A wants to impress person B. Person B wants to make person C look bad. Person C needs to go to the restroom, but doesn't want to say so. Person D is distracted by illness of his/her spouse.

Only Weinberg would write about hidden agendas in code reviews - too many writers and books on software development practices seem to assume that people act like machines.

On Weinberg's SHAPE forum, Charlie Adams wrote: "When people are getting tense about their software being reviewed, use Jerry's phrase, 'Yes, I trust your honesty, but I don't trust your infallibility. I don't trust anyone's infallibility.' (Quality Software Management: Anticipating Change: page 220) In my experience this has always calmed the atmosphere and allowed us to examine the code rather than the developer."

While I have done code reviews, both informal and formal, I prefer pair programming. It combines reviews with collaborative design, testing, and coding. Rather than go into all the reasons why pair programming is good, I'll point you to www.pairprogramming.com and Pair Programming Illuminated.

Available and Seeking Employment

I am available and seeking employment.

I am now extremely interested in getting back into product development and away from Agile Coaching. I am particularly interested in programming for the iPad and iPhone and Macintosh, and I would appreciate it if you, a reader of this blog, consider me for "mobile" or "Macintosh/cross-platform" Senior Software Developer positions.

As a technically-oriented Agile Coach for the last 5 years, I have helped teams reduce their bug counts and increase their rate of feature implementation. When I coach a team, I dive into the source code, quickly analyze and understand it, and help the team refactor it for testability and improved design. I help them write unit tests and teach them test-driven development; and provide instructions in other parts of an Agile software development process using Scrum and XP practices.

I have coached whole teams (managers, programmers, testers) at clients including Google using C++ and Python on Linux, IronKey using PHP, C, and C++ on Linux and Windows, Nokia-Siemans Networks in C++, and Schlumberger in C# and C++ on Windows, and Huawei in C++, and provided training to developers at these and other companies including HP.

Previous to working as an Agile Coach, I have worked on whole life-cycle projects at

• Apple, in C and C++,
• Intuit, using Objective-C, Cocoa, Carbon and C++,
• Electronics for Imaging, in C++ and Java on Mac and Windows,
• Hoffbauer Inc., my first use of Objective-C on NeXTStep (the ancestor of Cocoa and CocoaTouch),
• Ideal Learning, using Object Pascal, Object C, and C++, and
• Kodak Health Imaging Systems, in C++ on Mac and Unix.
• Pixera, a digital camera startup, in C++ on Mac and Windows.

While at Google, I contributed code to Google's open-source C++ test framework gtest and provided technical reviews of Google's open-source C++ mock-objects framework gmock.

Sleep Patterns

In Brain Rules, and other publications, we now know that people fall into various sleep patterns: "larks," who wake and are most active in early in the morning; "night-owls," who are most active at night; and the unnamed majority, who keep "normal" hours.

In an internet search, I happened to find an introvert night owl who now had the option to take meds to sleep at the same times her husband and children slept, but wanted to keep her late-night awake time as her "private time": free to write, meditate, and observe the quiet night.

It sounds like a nice idea for a short story. Does she conform to normal hours, or stay a night-owl?