Category Archives: JavaPosse

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”.

JPR 2008: Monday evening

With most folks arriving on Monday (including those of us who had intended a Sunday afternoon arrival), the informal intro to the Roundup was a DIY dinner graciously hosted by Bruce Eckel.

There was a suitable amount of envy for Robert Cooper‘s über-thin laptop (and some interest in the Eee PC), but the hot conversational topic of the evening was Android. A few of the attendees had the Android SDK, and were ready with jokes about the Cylon eye and Knight Rider. The architecture looks to be very well-thought-out, getting favorable press even before hitting the streets.

The big idea is that of a completely open, level playing field for mobile application development, built on an elegant set of core application concepts. There’s also open source repository with a sample app by the Posse‘s own Dick Wall. The source for WikiNotes shows just how much can be done with a little Java and a little XML.

It was a great start for the week!

JPR 2008: Getting there

Last year it took us 15 hours to get from Memphis to Crested Butte, thanks to an airline equipment problem. This year we planned to travel out a day earlier, to have a day to settle in before the sessions started.

So much for that.

Everything was on schedule until we got into the Gunnison area, at which point limited visibility on the ground (down to a quarter of a mile, according to the captain) forced our flight to orbit in the hopes that conditions would improve. One feature-length film later, with no improvement in the weather, we returned to DFW. At least we got to visit family that evening…

The next day our rescheduled flight made it to Gunnison without delay.

GunnisonAirport

So after 31 hours we arrived in Crested Butte to blue skies, bright sun, and the deepest snow in 30 years, according to residents.

CrestedButte2ndAvenue

We stayed at the Elk Mountain Lodge for the second year in a row, and were very happy with our accomodations (see below).

I spoke to one attendee who made it by a round-about route from Israel to Crested Butte in about 35 hours, which didn’t top our travel time by much. However, I’m not complaining, because the Roundup was worth every bit of effort it took to get here.

But if it takes 63 hours next year, I’m going to consider driving.

ElkMountainLodge2008

Java Posse Roundup 2008

This is the starting point for a series of blog entries about the Java Posse Roundup 2008. The theme selected for the week is “Don’t Repeat Yourself”, a phrase that rings bells with most developers.

I’m not able to credit by name everyone who contributed to each session I describe. Between the rapid-fire nature of many of the discussions, my attempts to capture notes and participate, and the fact that about half of the attendees were new since last year, I’m more likely to have names for comments that really captured my attention/imagination, or that were from people I already knew (or who talked longer! ;-) ) And, of course, if any of the attendees want to remind me of who said something that I don’t credit, I’ll be very happy to make an update. The conference was all about collaboration and participation, and I want to support that spirit.

So, without further ado, here are the links to my JPR 2008 posts:

I’ll continue to add material non-real-time as I can work through my buffers.

Follow

Get every new post delivered to your Inbox.