Posted on 1 Comment

Don’t do anything stupid on purpose

It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.

Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose

Posted on

What does a collaborative team work space look like?

The following passage from a generally good article by Jon Evans struck a chord with me:

Open-plan offices, in particular, seem an impressively terrible idea. "Open plan layouts create massive distraction, damaging productivity," according to a recent analysis by the U.K.’s Channel 4. See also the related Hacker News commentary, which includes gems like "Most modern office layouts seem to be designed to screw with people’s fight or flight instincts all day," and "I’m a quiet type, and I often need time alone to think and write code and documentation. The ‘rah rah’ social types railroaded us…I am becoming bitter and resentful."

Continue reading What does a collaborative team work space look like?

Posted on

What development methods and practices do you support?

From time to time, something happens that reminds me that our espoused theories aren’t always congruent with our theories in use (see this summary for some quick background info on those terms). The author of an article I had cited as an example of "binary thinking" posted a comment asking how I had gotten the idea that he was pro- or anti- anything. I took the question literally, and started thinking about how any of us might get the idea that another practitioner was pro- or anti- any given software development practice. Continue reading What development methods and practices do you support?

Posted on 1 Comment

Best practices for software development

There’s no shortage of advice about best practices. Naturally, commercial enterprises like IBM and Construx have advice. Their advice is designed to lead people toward their products and services. Of course, that’s because they believe their products and services support best practices. After all, they designed their products and services on the basis of what they consider to be best practices. So, it’s all good, right? They’re financially successful, so we can trust them. Besides, everyone knows that commercially-packaged best practices are carefully designed and well proven.

Individual practitioners are also eager to share the practices they have found "best" in their work. Their advice can be helpful, provided we remember it tends to be opinionated ("Git:Mercurial = Assembler:Java" — not "practices," BTW); haphazard and idiosyncratic (not to mention sexist and poorly written); specific to a single technology (and poorly written); or a rehash of generalizations (supported by questionable references). Like this Wikipedia article (as of 24 July 2013), such advice "has multiple issues." Continue reading Best practices for software development

Posted on 1 Comment

Elevator etiquette and self-organization

It’s common to borrow terms from the physical sciences and apply them to other domains. A football team can gain momentum during a game. People tend to cling to habits because they have inertia. A software development team tracks its velocity. When we investigate the nature of the interactions of individuals in a group, we talk about self-assembly and self-organization.

I suppose there’s no harm in this, provided we remember we’re using metaphor and we remain aware of the context. As the saying goes, "The map is not the territory." Continue reading Elevator etiquette and self-organization

Posted on

The Shimmering

In the movie, Now You See Me, a certain idea was stated multiple times, phrased in various ways: "Look closely, because the closer you think you are, the less you will see." In the past decade, a lot of people have been inching closer and closer to something called "agile," and most of them are pretty sure they can see it.

Things are very different on each side of the "hump" in the diffusion of innovations curve. On the left side, the early side, where the Innovators and Early Majority adopters live, people tend to be forward-looking, open-minded, imaginative, proactive, and willing to take risks. On the right side, the late side, where the Late Majority adopters and Laggards live…well, not so much. Some people are interested in the left side, because that’s where breakthrough ideas are vetted in the proverbial fire of the (possibly over-rated) Real World. Others are interested in the right side, because that’s where methods and practices become scaled, integrated, and institutionalized to support large enterprises. Continue reading The Shimmering

Posted on 7 Comments

Does pair programming work?

The fact this question continues to come up time and again after all these years prompted me to wonder why the matter hasn’t been settled by now. Thousands of people have tried their hand at pairing in a wide range of circumstances. Some swear by the practice and feel as if something is missing when they must work solo. Others are convinced pairing is pure waste and cannot possibly yield good results. Both opinions are informed by real-world experience. What specific differences in these situations resulted in such radically different outcomes?

Continue reading Does pair programming work?