I enjoyed several days in Southern California (SoCal) the week before Christmas. It had been several years since I had last visited Disneyland, California Adventure, Sea World, Universal Studios, and San Diego Zoo and it was fun to experience some of my favorite attractions (such as Soaring' Over California, Star Tours, Penguin Encounter, Universal Studios Studio Tour) and to experience some new (to me) favorites (such as Toy Story Mania!, The Twilight Zone Tower of Terror, Revenge of the Mummy, The Simpsons Ride, and Wild Arctic Ride). As much fun as it was to visit these amusement parks and zoo, the most significant downside was the large crowds (especially at Disneyland).
Despite the well-laid plans and valiant efforts by the staff members of these various parks, things did not always go as smoothly as they could have because some park visitors did not cooperate with these plans and staff directions. I couldn't help but see many similarities in software development where the best-laid plans, standards, code conventions, and other devices designed to improve productivity, maintainability, and other desirable "ilities" are less effective because a (relatively) small number of people do not cooperate. In this post, I look at some of the reasons and motivations that explain why a small minority of developers (sometimes only one!) often derail or at least reduce the effectiveness of various software development approaches and tactics. Because software developers are simply a subset of the human population, it is not surprising that the same reasons and motivations apply to software developers as to park visitors.
Explanations for Inefficient Behavior
If a particular code convention, standard, or other common approach is available to increase the productivity and maintainability of software, why wouldn't every software developer follow these standard approaches for the betterment of the entire organization? The answer to this question is essentially the same as the answer to the question, "If the parks have set up certain strategies and traffic flow patterns for an improved experience for all visitors, why wouldn't every visitor follow these practices?"
Don't Know Better
One significant cause of delays in trying to optimize crowd flow throughout the parks was the seemingly unpredictable behavior of small children. Many small children would dart any which way they wanted without regard to any directions or common sense as to what was the most effective approach. Of course, this was entirely to be expected and not at all surprising. Many parents tried to teach their children to be more careful about what they were doing. It reminded me of more experienced developers explaining to new developers why certain seemingly mundane or useless approaches might actually be worthwhile for individual and overall benefit.
Just as most people seemed to not be too bothered by young children making these mistakes, it is typically less bothersome when an inexperienced developer does not fully realize the advantages of following certain approaches designed for overall benefit. In both cases, it is often simply a matter of education to help the young child or inexperienced developer understand the value of following the plan.
Unaware of Plan, Approach, Convention, or Standard
Some of the people who were trying to walk "against the grain" seemed to be doing so simply because they were oblivious to the fact that, especially in the large crowds on Disneyland Main Street around parade and fireworks times, there was actually a preferred flow of people that Disneyland staff was trying to communicate.
Most of these offenders were adults and I like to think that many of them would have done as instructed if they had realized there was actually a plan. I liken this group to experienced developers who would follow the standard or convention once aware of it, but may not be aware of it due to being new to the organization or project. Again, this group is relatively easily helped by simply making them aware of the standard or convention.
Doesn't Apply to Me
Although many of the people at the parks and zoo who slowed everyone else down by going against the directions and traffic plans did so because they didn't know better or didn't know there was a specific plan, there was a small number of people who seemed to know better but chose to do what they thought was in their own selfish interest despite the negative consequences others experienced because of their actions. In some cases, this was a manifestation of a person believing he or she was more important than anyone and everyone else. In some cases, the offender appeared to believe that his or her actions would not cause any problems. Of course, they almost always did because everyone else was moving in conjunction and the entire group had to slow down to accommodate that person.
I actually heard one angry visitor at Disneyland say to the Disneyland employee instructing her to walk counter-clockwise around the circle between the Castle and Main Street in Disneyland reply that she would not do that. She said, "No. I'm not doing that. Sorry." She was obviously not truly sorry and felt that taking the extra 15 to 20 steps to go that way rather than the other direction was beneath her. So, of course, she slowed everyone else down who was following the prescribed path as she tried to make her way upstream through the traffic. There's no question it took her longer to get to her target location (albeit with fewer steps) and it slowed many times that number of people down at the same time.
In software development, we often see a developer who fits in this group. He or she thinks that the general approach does not apply to him or her. Sometimes this is because he or she simply doesn't want to do it and feels like doing his or her own thing won't have any serious consequences. Other times, the individual simply believes he or she has a better way and that the general approach does not apply to him or her. Not only can such behavior reduce the level of benefits from a general approach, but it can actually lead to even more detrimental behavior as The Prima Donna Effect kicks in and other developers start doing their own thing as well.
In development, a developer occasionally truly believes he or she is saving time by doing something outside of the prescribed plan, but this is often a false illusion that ends up being as bad or worse while also slowing others down. The problem is that even if the lone developer's approach is better on a single developer basis, its full benefit is only likely to be realized at an organizational level if that better approach becomes the commonly accepted approach or at least becomes compatible with the commonly accepted approach. It doesn't help overall effectiveness if one developer's saving of an hour costs five other developers an hour each.
Specific Software Development Examples
In the parks, the plans that seemed to not be as effective when visitors were either not aware of the grand plans or chose to ignore them generally involved things such as traffic flow, queuing up for popular rides, and queuing up to purchase souvenirs. The parks typically had directions and plans to make these things more efficient, but these efficiencies were lost when people ignored them. In software development, we have a similar set of well-known approaches that can be less efficient or not efficient at all when one or a small number of developers either are not aware of them or choose to ignore them.
Code Conventions
One frequently used software development approach that fits this idea is the use of code conventions. Code conventions are designed to make it easier to read and maintain each others' code. Even if the code convention is not our favorite, it is often easier to recognize and quickly read code that is similar in nature rather than code that is drastically different depending on who wrote it.
Another advantage of code conventions is less temptation for a developer to change another developer's preferred code style to his or her own code style. If both the original developer and all future developers maintain the code convention, then only significant code changes should be tracked in the configuration management system. This is no small advantage because style changes can often overwhelm "real" changes in software and make it difficult to determine what things of significance were changed from one version of code to another. Tools such as Jalopy can be useful in helping with this effort, but code reviews and adherence to the convention by developers is probably still the most effective mechanism.
Adherence to Standards
Most implementations of most standards supply some optional non-standard features that can be tempting to use. In fact, in some cases it might even be justifiable to use the non-standard features because its benefits outweigh the risks and costs. However, if an organization or client has mandated complete standards compliance, it is not appropriate for developers to use non-standard features of a particular standard implementation simply because it is easier. It may be appropriate to use the non-standard feature because the cost of not doing so is so great, but this should be coordinated and approved if standards compliance is key desirable characteristic (which it usually is). It can seem harmless to include use of a non-standard feature, especially if it is in a seldom used portion of code and/or is associated with a product that seems to be a permanent part of the delivered software. However, even the same vendor might change or remove a non-standard feature and there are never any guarantees.
Process and Logistics
A significant portion of the software development experience is associated with everyday, routine logistical tasks and process steps that are not specific to software development. Arranging for meeting rooms is an example of one of these routine tasks not specific to software development. Most large projects have procedures in place for reserving meeting rooms or any other relatively rare resource. When some individuals choose not to use those processes, they waste others' time waiting for them to vacate the room or arguing over who gets the room. Similarly, starting and ending meeting in a timely manner is a generally accepted practice that will generally benefit the entire organization when observed.
What About Thinking Outside of the Box?
One of the MBA euphemisms I most enjoy making fun of is "thinking outside of the box." It is popular to advocate thinking outside of the box and to encouraging non-conformists. Indeed, in the correct place and time these are valuable to keep an organization fresh. However, rather than one individual bucking the standards and conventions laid out so that everyone else is slowed down, it is better to work to have the general approach adjusted to appropriately incorporate fresh concepts while still retaining the value of having everyone moving in the same direction. Only if a single developer could do all development and maintenance of a product by himself or herself for perpetuity would the going solo approach be the best for an organization.
I have definitely found many places in a standardized approach where small, individual tweaks have improved my own productivity without negatively impacting others. I try to be cognizant of these almost instinctive maneuvers and advertise them to others around me. However, I have caught myself slowing others down when I have left the agreed upon approach and that is a difficult position to defend. In fact, even at the Southern California parks, I am afraid that at least once or twice per day I was the offender trying to save myself some time, only to realize I was costing others a couple of seconds because of a well-intentioned but ultimately poor choice that was not aligned with the greater plan.
Conclusion
It seems to be human nature to think that one can do something better than others and to seek individual advantage. I believe that the majority of us won't do this at significant cost to others, but we are very likely to do this if we believe it will have negligible cost to others. Unfortunately, our estimates and assessments of the potential cost to others is often incorrect and understated. It is often true that small sacrifices on our part will lead to organizational benefits and sometimes will even surprise us with benefit to our own progress.
The accumulate negative effect of a small number of visitors intentionally or unintentionally neglecting the provided guidance for how to allow the crowd to move about park most efficiently reduces the desired collective efficiency gains. Similarly, the intentional or unintentional neglect of provided guidance in certain areas of software development reduces efficiencies associated with grand plans designed for group efficiency. In the end, the individual that does not heed to the generally accepted approaches slows down the entire group for a small benefit to himself or herself and sometimes doesn't even see any benefit for himself or herself.
No comments:
Post a Comment