Category Archives: Extreme Programming

Extreme Programming, Scrum, Simplifying Software

Only One Retrospective Action-Item at a Time

Retrospective meetings are probably the most misunderstood and underutilized aspect of agile development.

If you know the expression, “the three most important things in real estate are location, location, location,” then you can relate when I say that the three most important things in software development are feedback, feedback, feedback. And, one particularly powerful feedback mechanism is the retrospective meeting. It’s how the developers give feedback to themselves — about their own processes.

I like to hold retrospectives early and often, at least once a week, sometimes once a day. That way, I can capture ideas while they are fresh on everyone’s minds. To make up for it, the retrospectives are kept short, 15 minutes MAX. In fact, if they go longer than 5 minutes, then something is wrong.

Why so short? Continue reading Only One Retrospective Action-Item at a Time →

Extreme Programming, Simplifying Software

Java Coding Standards

One of the first things I did after joining PICS was to set up a study group around Bob Martin’s Clean Code book. At the same time, I handed out copies of my principles-based Java Coding Standards document, a document that I’ve been giving out to my clients over the years and which is based largely on Clean Code, but also other works (see the references section on p 1). I just realized that I never uploaded that document here, so here it is: Java_Coding_Standards.pdf

Please let me know if you find this useful, and/or if you have any suggestions for future updates.

Events, Extreme Programming, Simplifying Software

TDD Slides Posted

2 Comments

Here are the slides (as a PDF file) for the Intro to Test-Driven Development speech that I gave at the SCQAA meeting last night.  I haven’t seen the speaker feedback forms yet, but based on the comments from people walking up to me afterwards, it was an effective speech.  In particular, everyone loved my grand experiment to demonstrate TDD — without requiring any programming knowledge — by having the audience break up into teams and write limericks test-driven.

If enjoyed this speech, then you might also be interested in materials from other speeches that I’ve given in the past.  You can find them on the Downloads page.

Extreme Programming, Simplifying Software

Pondjumpers Podcast Episode #9 is Out

The Pondjumpers podcast is about (agile) software development in open source communities.  It’s hosted by two self-confessed geeks on either side of the Atlantic: Greg Turnquist of SpringSource (the originator of Spring Python and currently on the TC Server team), and Russ Miles of Open Credo (consultants specializing in building open source communities).  Their first hour-long episode came out in June 14, 2009, and they publish a new one about every other month.  It’s available on iTunes or at http://pondjumpers.com, and you can follow them on Twitter at pondjumprs (http://twitter.com/pondjumprs).

Overcoming Delays – No Silver Bullet

Where past episodes have featured interviews with developers of various open source projects, this episode is devoted to a discussion between the two hosts.  One of their main themes this time around is overcoming delays in software development, from delays imposed by the technology to delays imposed by time zones separating distributed team members.  In particular, they discuss how companies looking to “lower the waterline,” increasingly realize that there is no silver bullet — that it’s always a matter of scrutinizing lots of little things.  Shaving a few minutes here and even a few seconds there all add up.  We’re talking about things like speeding up unit tests, speeding up the compile/run/debug cycle, and how long it takes to commit code to a branch and then merge it into the trunk.  These kinds of time savings make the difference between being able to consistently deploy new code to production in terms of days and weeks rather that weeks and months.

On a related subject, Turnquist and Miles stress the importance of automated continuous deployment (not just continuous integration) complete with “smoke tests.”  Another topic covered is the popularity of distributed version control and, specifically, the trials and tribulations of moving from Subversion to Git.

If Pondjumpers resonates with you, then keep an eye out for a new podcast series that Russ Miles is involved in producing for Open Credo.  It will feature screencasts and videos devoted to, as Miles boldly puts it, “software development in the real world.”  For this endeavor, Miles is aiming to focus on interviews with “honest, no-holds-barred doers.”

Extreme Programming, Simplifying Software

Taking the Stick

A front page story in this morning’s USA Today talked about airline safety and how improper simulator training for pilots often causes accidents.  Flight simulators, no matter how impressive the technology behind them, are not perfect representations of actual flight.  Yet, the airlines rely on them for the bulk of new pilot training.  So, under certain circumstances, pilots take the wrong actions because they react to how the simulator works, not to how the plane actually works.  This is proof that the old adage “practice makes perfect” isn’t quite right.  The saying ought to be: “practice make permanent.”  Practice the wrong things, and you just get good at doing the wrong things. Continue reading Taking the Stick →

Extreme Programming, Scrum, Simplifying Business

Take 5 – A Tip for Running Retrospectives

Quite by accident, I discovered a bit of magic to running a 2-hour retrospective meeting. Halfway in, between the brainstorming part and the planning part, I needed to find a resource on my laptop that was eluding me (a file I had misplaced). So, I called for a 5-min break. I left the conference call phone bridge up and told the distributed team members to just set down their phones and come back in five.

What I discovered is that a few people hung out during the break and started to chat socially across the phone bridge — on the subject of marathons and bike races, in this case. I realized that it was a rare occasion for the distributed team to bond on something other than work. So, I let the conversation continue for a good 10 minutes after the break. I also realized that when we eventually got back into the task of turning our brainstorms into action items, it was with a clean slate and a slightly elevated outlook. I’m positive that the decisions we made during the second half of the meeting were better than they would have been had we gone straight from brainstorming to acting. For one thing, the break allowed everyone to unhook themselves from their particular brainstorm contributions and come back at the whole list with a wider view.

So, from now on, I’m going to find any excuse to take a break, and I’ll be sure to specifically prompt everyone to “chat amongst yourselves while I’m busy doing X.”

Events, Extreme Programming

Pair Programming Roundtable at SD Code Camp, Interested?

Do you plan on attending the San Diego Code Camp the weekend of June 26-27?  If so, please consider voting for the session I submitted, “Getting the Most out of Pair Programming.”  To vote, go here: http://www.socalcodecamp.com and log in (or register), then click on the Sessions tab, scroll down the the G’s (alphabetical by title), and check the box next to the “Interested” count.  Thanks.

Here’s the Session Description I Submitted: I’ll start with a 10- to 15-minute presentation of my experiences with pair programming going back 10 years Continue reading Pair Programming Roundtable at SD Code Camp, Interested? →

Extreme Programming, Simplifying Software

Test-First Development Can Be Liberating

Experienced agilists talk about becoming “test infected.”  For everyone, unit testing starts out as a chore that seems like it’s more work than it’s worth, but then you get over a certain hump and suddenly unit testing is a breeze.  The benefits become manifold and profound, and you begin to wonder how you ever programmed without it.

One important milestone on the way to achieving test-infected enlightenment is the transition from test-after to test-first.  All developers start out writing the production code first and then write unit tests around it.  It’s the only way we learn.  But, eventually, we begin to see the power of writing the tests first.  This used to be called Test-Driven Development, but it’s more accurately referred to as just Test-First Development (although we still abbreviate it as TDD).

For me, the greatest thing about TDD is that it gets the subjective part of the problem out of the way early, leaving just the objective part to puzzle out.  “Okay, now that we know what we need to accomplish, we just have to get it to work.”  It’s a rather liberating feeling. Continue reading Test-First Development Can Be Liberating →

Extreme Programming, Simplifying Software

Lessons in YAGNI

YAGNI stands for “You Ain’t Gonna Need It” (yet).   It’s a mnemonic meant to remind us developers not to speculate. That we should only put in code that addresses the task at hand and worry about tomorrow’s challenges tomorrow. There are many good reasons for this advice, the chief among them being that situations may change between the time that the speculative development happens and the need for the feature actually arises. In that case, the speculative development will turn out to have been wasted development time that could have been spent on addressing more immediate problems.

I thought I had learned this lesson years ago. I thought I was pretty sensitive to YAGNI and had a good track record for resisting it. But, recently I introduced a bug in a system that I was working on, and the ultimate reason for the bug is that I had committed the “crime” of speculative development. Continue reading Lessons in YAGNI →