Daily Archives: 2008-03-15

JPR 2008: Tuesday afternoon

During the afternoon break, Dianne Marsh took Dick Wall, Mike Levin, and me to the Crested Butte Nordic Center for a bit of cross-country skiing. (Dick and Mike had tried xc before, so I was the rank newbie.) Dianne was a very patient and helpful babysitter. I didn’t fall down once. (*)

I took the picture below…

NordicCenter

…looking back down a small hill toward Dianne and Dick standing by the Nordic Center building. The snow on the right side of the picture (between the building and the ice rink) really is as deep as the second-floor balcony. The next picture…

IMG_2733

…was taken only a few dozen yards further on (after Mike had joined us and everyone had passed me, which wasn’t hard ;-) ). This shot illustrates that the beauty of nature is only a few steps away, almost no matter where you are in Crested Butte.


(*) The statement above is true, strictly speaking. I actually fell down about a half-dozen times. ;-)

JPR 2008: Tuesday morning, part 3

“70% Rowing Backward: Why is software development so messed up?”

Bruce Eckel convened this session, inspired a statement he heard from Cameron Purdy of Tangosol:

“70% of programmers are writing code that is going to have to be fixed to move forward.”

(Purdy is known for other insightful statements in the past…)

Bruce immediately clarified that he was not referring to deliberate misbehavior, but rather to effort expended by people who thought they were doing the right thing. The question behind the question was, “Why is it so hard for developers to keep in synch with each other and with the organization’s goals?”

As we discussed the issues, answers included:

  • education out of touch with the current software development, because of:
    • a focus on theory to the exclusion of application and best practice,
    • a focus on short-half-life skills without conveying the underlying concepts, or
    • a focus on a single language or platform without showing the bigger, longer-term picture;
  • curricula with no practice-oriented components;
  • no (or infrequent) code reviews, so that large amounts of code get written before anyone but the (single!) author sees it;
  • division of labor (e.g. framework dev vs. application dev.) with inadequate knowledge-sharing between dev groups; and
  • production environments and architectures which make rapid deployment (and rollback, when necessary) painful.

There was a fair bit of discussion about code reviews, especially about the fact that the most effective reviews are done by (or with) the most experienced developers. Under that assumption, how can code reviews be done without saturating the senior people? Several options were suggested, including:

  • on-line code reviews, via such tools as Google‘s Mondrian and Atlassian‘s Crucible;
  • frequent code walk-throughs (i.e. take small bites often, don’t try to swallow the elephant all at once);
  • pair programming (of course); and
  • post mortem discussions per load or milestone (common at Google, especially for problem cases).

The post mortem topic generalized into a the question of how to increase communication, both within a team and across teams (even including non-developers). Google has “grouplets” that meet to discuss common issues, concerns, and techniques. Some companies use reading rooms or tech talks for the same goal. Dianne Marsh‘s company holds lightning talks every other Friday. Others reported officially-sanctioned “long coffee breaks” as an opportunity for cross-pollinating conversations. Barry Hawkins mentioned weekly talks (any topic allowed: technology, post mortem, etc.) held on Friday mornings right before lunch as an effective stimulus for informal follow-up conversations.

A more formal approach added to the mix was the use of a structured panel discussion. A request for topics was made a month in advance, the collected list was redistributed for voting, and the winning topic(s) provided the subject matter for one or more panels.

Several people responded to the point that personality and personal responsibility are crucial. It’s easy for a programmer (responding either to schedule pressure or a desire for higher productivity) to go “heads-down”, but there’s a risk that (s)he will lose sight of the big picture by doing so. Worse, some developers seem to want to “stop studying and just do it”, while others see learning as a career-long process. A popular, related theme was the need to retain humility and a beginner’s mind, rather than becoming a self-perceived expert (a small boy with a hammer, who sees everything as a nail). Regardless of what our environments offer us, we are responsible for our own skills and development, and for our influence on those with whom we work. Carl Quinn admitted, “We drag the quiet guys to lunch.”

Returning to the environment and organization, we also discussed physical set-up (cubes, offices, open space), technology (using a chat server to support constant, open communication), employee life-cycle (aptitude testing for applicants, “how we do it” training for new-hires, mentoring, and internships), and relationships with other parts of the organization (e.g. having a project-level “war room” in common with development, QA, marketing, etc.)

There were also complaints about interruptions and noise from non-development co-workers who don’t respect the times when a long attention span is needed. This was balanced by recognizing that developers can’t “go dark” for so long that they loose communication and shared vision.

In fact, I perceived balance as a constant theme throughout the discussion. A successful software development organization must be alert and flexible enough to maintain a dynamic balance among a number of forces:

  • short-term demands vs. long-term vision,
  • flexibility vs. formality,
  • constant communication vs. quiet “think time”,
  • moving among the roles of craftsman vs. engineer vs. scientist,
  • popular “building trades” and “factory” metaphors vs. the unique pressures of fast-moving technology,
  • the legitimate business needs of cost and schedule predictability vs. the equally legitimate difficulties of dealing with highly-complex systems and incomplete or ad hoc requirements, and
  • moving the art forward vs. dealing with what we have today.

Of course no one argued with the strategy, voiced late in the session, “Hire smart people and turn them loose on a problem!”


Suggested follow-up reading:

Pair Programming Illuminated
QBQ! The Question Behind the Question: Practicing Personal Accountability in Work and in Life

JPR 2008: Tuesday morning, part 2

“Startup Mistakes Not to Repeat”

Although I’m not in a startup software company, I found much of the discussion to be relevant to software developers in other environments. The participants described a variety of startup experiences, with the expected aspects of stress, excitement, and occasional burnout. I was impressed by how often the discussion included:

  • the roles and contributions of all parties – developers, marketing, executives, and venture capitalists;
  • the importance of mutual respect;
  • the critical role of simple (and frequent) communication between developers and non-developersn;
  • the variety of ways that developers and non-developers were able to achieve teamwork and common cause:
    • weekly lunches,
    • video game rooms,
    • joint customer calls,
    • and crossing traditional “boundaries” to ask others what they’re doing and thinking.
  • and being able to look back and value the learning and growth achieved in the face of difficulties.

After a short break, and some Camp 4 Coffee, we were back at it. My second session of the day was, “70% Rowing Backward: Why is software development so messed up?”

JPR 2008: Tuesday morning, part 1

Given that about half of the attendees this year were alumni of JPR 2007, it’s no surprise that many sticky notes were posted even before the opening session began.

IMG_0288 IMG_0289 IMG_0291 IMG_0292

Bruce called the opening session to order with the by-now-traditional warnings about the risks of altitude sickness and dehydration. After a few more suggestions and a discussion of optional activities for the week, he explained the protocols for open space conferences, including The Law of Two Feet (near the bottom of the linked page).

After a bit more posting, shuffling, and negotiation, we reassembled ourselves for the first topics of the morning. I sat in on the session entitled, “Startup Mistakes Not to Repeat”.

Follow

Get every new post delivered to your Inbox.