Home > Blogs > A Consistent Approach, Where Needed

A Consistent Approach, Where Needed

There is great value in having a standard way of doing things we need to do more than once. This applies in the home, and can be extended to how we develop software as a team...to a point.

My wife has a way of dealing with the laundry as it goes from the hamper to washer to dryer to drawers, and she knows where the dirty clothes are and where the clean ones are. I've got my system for loading the dishwasher, to make sure I can pack it as completely as possible but still making sure they come out clean. We each have our own distinct way of getting the kids ready for school in the morning, and it is best to let one person take the reins if we are both around.

Our standard approaches have evolved over time, and with depth of experience comes efficiencies that we have made standard practice. We've grown our approaches, we are comfortable with them, and to some degree we are attached to them. They are ours, after all.

While we each have our way of doing things, there are clearly times this way is not well understood by others that may have to deal with it. I've been known to yell upstairs to to ask about the state of this or that pile of laundry, and while I've never been asked my opinion, there are times I'll dive in and shuffle things around in the dishwasher. I'm sure I will learn the truth when my wife reads this entry.

As we develop software, especially when we are in an environment that does not provide an established and managed way of doing things, we come up with our own way of dealing with repetitive tasks. At the detailed level, we might follow our own approach to interacting with our CM systems, or for validating our code. If we're charged with managing the daily builds for our product, in most places any automation is supplemented by a series of simple little manual steps that we know by rote (after learning the hard way). We develop a standard place we refer to for information about the latest part of the application we are building: while the ideal is to refer to well-managed and current scope or design information, the standard place is more likely to be the copy of the spec that we keep in our own space, or to go to the source (the analyst, or architect, or end user) for their latest opinion of what to build.

Many of the approaches we use to build software are carried over from our last jobs. Changing jobs or companies can be quite disruptive, and to bring with us our internalized approaches gives us that little bit of comfort, that jump-start of knowledge, that one less thing we need to learn here. There are even times where we simply assume that this is the only conceivable way these things could be done anyways ("Who in their right mind would think that the effort to build an automated test suite would save me time")

Our systems give us individual efficiencies, but these rarely scale well to a team environment. I'm sure you have collided with other people's systems when they were out of the office for a day or two and you had to pick up where they left off. For more than a few teams, there is one go-to person that can build the product successfully, or even manage the nightly backups without a hitch. When we need to swap roles, even temporarily, the challenges of individually built approaches to work become painfully apparent.

One of the things that I ask teams when I start to work with them is their approach to development. The response for almost every team has been the same, in that they are all inconsistent. While they may identify one approach over another, few teams are consistent in their understanding of how they get things done. Even when most people on a team suggest that they have adopted one of the agile approaches, or a variation of the unified process, or are CMMI-based (though I can't quite comprehend how that maps to a specific approach), there are problems.

One problem is that it is only most of the team, not all of the team. There are always those that either haven't subscribed to that party line, or haven't been told what it is to begin with. The second problem, likely related to the first, is that once we dive into the details, even with a named approach, it has rarely been appropriately tailored, consistently deployed, and conscientiously monitored for application and effectiveness. Almost every team, when we get down to it, is ad-hoc.

If the team is small enough, this is not an overwhelming problem. If you can call over your shoulder to discover where that last build component is (or whether this load of whites should have bleach), you can still do well without much more fostering of consistent practices. Indeed, keeping the team small is one of the more credibly justified practices for project success, if it is appropriate for the problem at hand. As the team grows, so will the cost of the collisions associated with ad-hoc practices.

Given my experience, most teams would benefit from a bit more careful management of the approaches to getting things done. Individual perspectives can be leveraged to develop approaches that are both commonly understood, and eliminate the pitfalls of either of the earlier viewpoints. Team members become more interchangeable, and the bus-hit-the-hero corporate risks will drop. Most importantly, you will reduce the frequency of the phrase "What the heck were you thinking?!" on your projects.

As we start to recognize this, there is the danger that we go overboard in the other direction. There is no need to make every practice consistent, as long as the product of that effort satisfies everyone’s needs. It's not critical to identify a dress code or a time when people should respond to e-mail, but issues like where to go for critical information, how to manage change, or what closure means for a piece of code being developed should all be carefully managed. If doing things in different ways will disrupt the project, it is worth making consistent. If the end result is still adequate despite a different approach being taken, don't sweat it.

Now I need to get back to redoing that load of whites...