Development organizations are often concerned with finding out what “best practices” they should employ to help ensure a successful product. But practices don’t always transplant well. Rather than adopting someone else’s practices, you might want to derive your own from basic principles.
The bowling story
Many years ago I took my younger daughter to the bowling alley for an afternoon of fun. I hadn’t been to this particular bowling alley before, so was unfamiliar with their policy regarding shoe rental.
When I asked the young lady behind the desk for a lane and shoes, she responded, rapid fire with, “I-need-a-shoe-size-and-a-shoe.” It sounded like all one word.
I didn’t understand what she had said, so I asked her to repeat it. Again she said, “I-need-a-shoe-size-and-a-shoe.” This time I caught the words “shoe size,” so I replied, “Ten and a half.”
She plopped a pair of size ten-and-a half bowling shoes on the counter, then said, “And a shoe.”
I was puzzled. “What?” I asked her.
She repeated, “And a shoe.”
“I don’t know what you mean,” I replied.
“I need one of your shoes.”
“Why?” I asked.
Instead of answering me, she pointed to a sign on the front of the counter which said something to the effect that customers are required to leave one of their shoes at the front desk at the time of bowling shoe rental.
I looked back at the young lady (who was probably already tired of dealing with me) and said, “That’s not why, that’s what.”
A few moments of awkward silence told me that she was disinclined to explain further, so I gave her one of my street shoes, collected the bowling shoes, and walked toward the lane she had assigned us, a little off-balance, one shoe off and one shoe on. (Diddle diddle dumpling, my son John…)
Bowling alley policy – principle vs practice
By pointing to the policy statement, the young lady was indicating the bowling alley’s practice regarding shoe rental. That told me the what, but not the why. By the time I arrived at my assigned lane, I was able to infer the why, which likely had something to do with people literally walking off with bowling shoes. (A quick conference with my daughter tended to confirm this hypothesis. She told me that a number of her friends occasionally wore bowling shoes to school.)
Thus I was able to infer the principle involved, which might be expressed as “some customers will steal our property unless we hold onto something of theirs that they value more than our property.”
Practices may not transplant well
Now let’s suppose that the owner of another business, say a miniature golf course, decided to enact a similar policy (after, perhaps, speaking to the bowling alley owner who expressed that theft was all but eliminated after implementing the “shoe policy.”)
And let’s further suppose that the miniature golf owner hopefully and enthusiastically has a sign made up and displayed prominently, stating that all people playing miniature golf must leave one of their shoes at the counter, hoping to eliminate theft of the occasional putter.
You can imagine the results. Rather than reducing theft, this policy will likely have the effect of reducing revenue, by thinning the golf course’s customer base down to those who enjoy playing minus a shoe.
And, of course, no reasonable person would actually implement a policy that was as ill-fitting as this. The mismatch is too obvious. Instead the owner of the miniature golf course is likely to infer a principle from the bowling alley practice, then implement a similar practice appropriate to the miniature golf business, perhaps something like all people playing miniature golf must leave a small cash deposit at the counter.
Principle vs practice in a development environment
Development (and especially software development) organizations seem to like the idea of finding and applying what they call best practices. I’m not aware of any common agreement on what “best” means, but in my experience it almost always involves “something that someone else is doing.”
And while the differences between software development organizations may not be as glaringly obvious as those between a bowling alley and a miniature golf course, suffice it to say that differences (e.g. size, experience level, customer type, product type, etc.) do exist.
Pair programming is one example of a development practice that’s been around for a while now. In pair programming, as the name suggests, two developers work side by side, on the same code at a single computer. Proponents of pair programming cite increased quality, better design and instantaneous code review as some of its benefits.
I’ve worked on several projects where attempts to implement pair programming were made. Some worked well. Others, not so much. Generally speaking, I’d say that the unsuccessful cases occurred due to social, rather than technical, reasons. In all instances, everyone attempting the practice was technically skilled. But personality or style mismatches sometimes got in the way, making pair programming something other than a best practice in those cases.
Looking at principles rather than practices might have been helpful. So what principles might we have been able to infer? These come to mind:
- Having more than one person review code will decrease the defect rate.
- Code that is understandable to more than one person is more maintainable, and therefore less costly to the organization.
- Simpler designs result from collaboration
From the principles listed above, can you derive some practices that fit the unique composition and characteristics of your organization? I’m guessing that you can. What are they? I can’t say—I’m not in your organization. The practices that you come up with are based on generally applicable principles, but the specifics of those practices are highly dependent on your particular work environment. (In other words, you’ll have to figure them out for yourself.)
I’m interested to hear what you come up with. Are there specific practices you can derive from the principles listed above that would serve you better than pair programming? Please feel free to comment.