Monday, April 26, 2010

Turn Signals and Coding Conventions

In How Turn Signals Work, Karim Nice writes "Turn signals may be the most underutilized device on a car." I sometimes feel that when I witness drivers who cannot be bothered with indicating their intentions through use of a turn signal. Besides being simple common sense, the importance of using a turn signal to convey intentions to others is documented by multiple groups and individuals including driver safety informational sites, automobile insurance sites, law firms and legal information sites, a dedicated Facebook page, user interface articles/books, travel information sites, and odds of death and accidents statistics sites. Given that the New York State Police has listed failure to use turn signal properly as #3 (of 7) factors causing accidents, it is easy to wonder if people don't know how to use turn signals or why people don't use turn signals.

Coding conventions are much like turn signals in that they are often a preferred and expected form of communication between developers who might not have an easier way to communicate the same information. Unfortunately, some developers neglect and ignore code conventions the same way that some drivers neglect and ignore use of turn signals. This neglect, in both driving and in development, is often the result of similar motivations and can have negative consequences in both cases. In this post, I look at how use of code conventions for developers is like use of turn signals for drivers in terms of communication, consequences of ignoring them, and reasons used to justify ignoring the "common sense" behind both devices.


Increased Communication: Conveying Intentions

The importance of using turn signals to convey intentions is obvious. There is rarely another way, let alone a better way, to warn other drivers of one's intention to make a turn or change lanes. Other drives can make better decisions when they know each others' intentions. We've all likely seen the increased level of potential danger associated with drivers who are too distracted to even know themselves what they're going to do next. The defensive driver uses cues from the other drivers to be better prepared for different scenarios, but the intentional and correct use of turn signals is undoubtedly one of the best ways other drivers can help the defensive driver to know their intentions.

Just as turn signals provide an easy visual mechanism for drivers to use to communicate intent with one another, likewise coding conventions provide an easy form of communication between developers. Simple things such as proper indentation can make reading and maintaining others' code much easier, quicker, and more likely to be interpreted correctly. Likewise, other naming and style conventions can make it easier to communicate intent of variables, methods, and other pieces of code.

Comments are an obvious way to communicate between developers, but they have their drawbacks. While I'm not opposed to all comments, I do acknowledge they have their problems and that some comments are flat-out poor or unnecessary. In fact, one of my favorite software development quotes is "Comments are the deodorant for stinky code." Comments can get easily removed without affecting the executable code. Comments can become obsolete when developers fail to keep them current with the code changes. Naming conventions can get similarly out of synch, but it is less likely because the developer refactoring code using naming conventions is forced to at least look at what he or she is refactoring and realize that the name is becoming obsolete.

Naming conventions have become even more significant in software development in recent years with the rapidly rising popularity of "convention over configuration" (popularized by Ruby on Rails) and "configuration by exception" (popularized by Java Persistence API). These concepts rely on naming conventions to significantly reduce coding effort, but allow greater flexibility beyond the common cases when needed via explicit configuration. The point here is that naming conventions were recognized as a source of huge productivity gains and applied to a greater degree than many of us had used previously.


Consequences of Failure To Use

There are very serious consequences to failure to use a turn signal properly. Fortunately, in most cases, the consequences of failure to effectively use coding conventions are not as serious as those of not using turn signals. However, this does not mean that failure to use coding conventions is not without cost or consequence. It does not take much experience reading or maintaining other developers' code to quickly realize how much less productive one is in maintaining, reading, and refactoring another's (or even one's own) code when it was not written with a convention in mind. When the original developer's intentions are not well understood, it can be much more costly to change the code. In some cases, it may be next to impossible.

More than once, I've witnessed a developer "start all over" with some piece of functionality because understanding the existing code was proving too difficult and expensive. Some of this difficultly lies in strange logic, design pattern abuse, or use of anti-patterns, but lack of uniformity in code presentation can play a significant part in making software unmaintainable.


Dysfunctional Motivations

When I do encounter the driver who doesn't use his or her turn signal, I often wonder why. I have had my suspicions and research has largely confirmed them. In fact, a Response Insurance survey (1999 to 2005) found that over half of all U.S. drivers stated they do not use turn signals when changing lanes. The reasons survey respondents gave for not using their turn signals were surprising to some, but I think many of them are the same reasons some developers do not adhere to conventions. I look at some of these reasons next.

Missing the Point

The Response Insurance survey cited above found that young drivers were more likely to not use their turn signals than older drivers (though neither age group had a lot to brag about). This might be explainable by the fact that older drivers having more experience and close-calls or collisions due at least partly to failure to use a turn signal. Similarly, if new developers are the way I was when I first got out of college, they are not as likely to recognize the real benefits of adhering to coding conventions because in many college courses the only real advantage of following conventions is that associated with instructor expectations and grading schemes. The experienced developer has likely been burned more than once when another developer (or even the same developer) failed to adhere to conventions.

According to the Response Insurance survey, eleven percent of surveyed drivers that did not use turn signals chose not to because they didn't think it was important. The good news about this group is that they can be taught. They'll likely learn through hard experience even if it is when they have to maintain or refactor or read the code someone else wrote without regard to conventions. I first used conventions as a professional largely because my employer and customers mandated it. This isn't a bad way to get into the habit of doing it until the realization of its value comes.

Laziness

I've long suspected that the primary reason drivers don't use their turn signals is sheer laziness. It sounds terrible that people are too lazy to even make the slight movement necessary to turn on a signal, but I cannot say I was surprised to see that the Response Insurance survey found that nearly 1/4 of those who don't use their turn signal cited laziness as the primary reason. I don't think laziness would be the primary reason for as large of a percentage of developers who don't adhere to coding conventions, but it probably does account for a portion of them. Developers might be too lazy to read and learn the conventions or too lazy to make the effort to change old habits.

Insufficient Time

This one is scary in both driving and software development. The Response Insurance survey found that over 40% of drivers who don't use their turn signals cited insufficient time as the reason. It's frightening that drivers are making lane changes and turns with so little forethought that they cannot even signal a couple seconds in advance. I am sure that more than one developer has not adhered to a coding convention because it slows him or her down and he or she does not have time to bother with that. Again, this is frightening. If someone is so rushed that he or she cannot even adhere to a coding convention, the delivered product is likely to lack the forethought in design and the level of testing needed for a quality product.

Not a Habit

After many years of driving and using my turn signal the vast majority of the time, I have gotten to a point where I almost use it subconsciously. It is wired into me to use it when changing lanes or making a turn. Similarly, I find that repetitive use of coding conventions has a similar effect and that it becomes easier and more natural to use a coding convention as I consistently apply it.

It is sometimes tempting to not use a signal when there is seemingly no one around. One problem with this, however, is that if one drives a lot in such situations, one can quickly lose the habit of using the signal and actually build up a habit of turning and changing lanes without a signal. Similarly, there are times when I'm writing a piece of code that I know no one will be using or maintaining and I often think about not using a coding convention in such cases. However, I typically do follow a coding convention in such cases to make sure I stay in habit and because it is often easier to follow my convention habit than to try to temporarily stray from it.

No One Will See It Anyway

I mentioned above that using a turn signal or coding convention even when no one is around can be beneficial in terms of building or maintaining a good habit. There is another reason one might choose to signal or use code conventions when no one else is around or is likely to see the code: it might be a mistaken assumption that no one else is around or that no one else will read/use the code.

Suppose that another vehicle pulled onto a highway without being noticed and made the bad move of staying in the driver's blind spot. The first driver might assume that no one else is on the road and feel like he or she can change lanes without signaling. However, if the driver chooses to signal anyway, the second driver in the blind spot is given at least warning and can choose to do something to help the situation. Both drivers benefit. Similarly, I have seen too much throwaway code become baseline code to believe that any code will never be seen or used again. It seems safer for everyone involved to adhere to coding conventions even in "throwaway" code.

Intentionally Bad Behavior

What surprised many people the most about the Response Insurance survey was that seven percent of those who don't use turn signals stated that the reason for this was to "add excitement" to driving. Even taking into account that some people like to respond to surveys in a way that is more exciting than realistic for them, it is still disconcerting that anyone would behave like this with others' lives on the line. I don't think one runs into many developers who don't use code conventions out due to a level of excitement, but I do think we see developers who might choose to not adhere to coding conventions out of the ill-conceived idea that they have better job security if they make their code indecipherable (and not adhering to code conventions is just one of many ways to do this).

Selfishness

There seems to be an element of selfishness involved when a driver understands that there are communication benefits associated with using the turn signal, but chooses not to use them despite this knowledge. Similarly, the developer who has learned or understands the benefits of coding conventions is also demonstrating selfishness (laziness, job security, etc.) when he or she chooses to not use them despite this knowledge. In driving, this is misdirected because a bad collision may injure the driver choosing not to signal as much or more than the other driver. With code, not adhering to conventions may not result in immediate problems, but in the long run managers, customers, and fellow developers will recognize (not in a good way) that a certain developer refuses to follow standards and that will typically harm that developer's career and respect.

The longer I work in the software development industry, the more I see examples of where an otherwise good software developer is less useful or even not worth having because he or she allows selfish motivations to cloud his or her judgment and to do things that are not best for the customer, the employer, or even for the team. Stubborn resistance to *useful* (emphasis is intentional) coding conventions falls into this category.


Conclusion

With almost half of U.S. drivers not using their turn signal despite the fact that most probably understand that using a turn signal has advantages, it can be frightening to consider the "other driver." Likewise, the "other developer" is often a scary concept, especially when he or she chooses not to use effective software development principles such as adhering to accepted coding conventions. Using the turn signal and using code conventions have well understood benefits and experienced drivers and developers (as well as the best less experienced drivers and developers) tend to use these tools to their advantage. Unfortunately, not all drivers are of the same quality and not all developers are of the same quality. For a variety of reasons (some of which were covered here), some drivers and some developers do not take advantage of these simple mechanisms with significant potential advantages.

No comments: