Software Developers' Guilty Pleasures

The term guilty pleasure is often used to describe music, television, movies, or other entertainment that we might (often somewhat secretly) like even when many around us (especially in our peer group) mock that same specific entertainment. You have to be pretty comfortable with these guilty pleasures to acknowledge them to those around you.

I believe there are guilty pleasures in software development just as there are in so many other aspects of life. These software development guilty pleasures arise from situations such as the following:

* Writing code that does not conform to the expected conventions and standards.
* Writing code that is challenging, interesting, or helps learn something new even though the plain, old-fashioned approach might be satisfactory or even superior.
* Writing less code at any cost.
* Forcing certain design patterns, implementation patterns, or other design/implementation approaches on situations that don't warrant them.
* "Improving" or "refactoring" someone else's code to "fix it."
* "Improving" or "refactoring" our own code when it really is not necessary or requested.
* Favoring and using a product that is not used in our normal development environment.
* Having the ego stroked.

There are probably many more manifestations of guilty pleasures of software developers, but I will limit the remainder of this blog entry to discussing some illustrative examples of each of these types of software development guilty pleasures.


Rebellious Coding

I think most of us appreciate the value and benefits of certain coding conventions and standards. That being said, many of us can probably readily provide a wide list of times where we felt the imposed standard or convention was either not worth enforcing or actually a negative practice. It is difficult in these cases to not succumb to the guilty pleasure of simply doing it "the correct way" despite what the convention calls for. James Dean doesn't have anything on us.


The Allure of Resume-Driven Development and the Magpie Effect

Many of us just cannot help ourselves when it comes to avoiding this guilty pleasure and the examples of this are plentiful. In How to Use Groovy without Management Finding Out, the author provides a clear example of this guilty pleasure and even points out that the IDE could already do what the blog entry was about. Still, the author (and many of us reading the entry) cannot help but be fascinated by the ability to do the same thing with Groovy scripts.

Other examples I have seen of this effect include gratuitous and unwarranted use of recursion (where an iterative approach would actually be easier to understand and better performing, but lacked the coolness of recursion), needless use of EJB 2.x despite its complexity, and using a new product or tool that's only real known advantage is that it is new instead of using a well-understood tool.


Less Code is More Fulfilling

As with the two above, this is a guilty pleasure I can easily fall into. Part of the problem here is that it often is a good thing to write less code. One of my great sources of satisfaction in development is refactoring a large chunk of code (especially if there is lots of copy-and-paste development built into the code) into a much smaller, more maintainable piece of code.

Unfortunately, this generally "good" practice can be taken to the extreme. I have been the unfortunate person tasked with maintaining or adding to some extremely terse code with no comments and it was a time-consuming process to figure out what the intent of the code was. I definitely think it is better to have code speak for itself than to have comments try to describe what the code is doing. However, less code and descriptive code are not always the same thing. While fewer lines of code is generally better, fewer characters per line is not generally better.

Besides descriptive names, other situations sometimes require a little extra code. For example, while I like Java's ternary operator in several common cases, I don't like nesting these too deeply because too many people find those difficult and even exhausting to unravel. Similarly, I am not afraid to add an extra set of parentheses on occasion to better communicate the intent of the conditional even if I know that the operator order of precedence will be okay without the parentheses. On the other hand, I've known some developers who secretly enjoy seeing the struggles of others trying to read their terse code and/or their code that relies on nuances of the programming language. I think that qualifies as a guilty pleasure.


Maslow's Golden Hammer

Maslow's Golden Hammer describes the situation in which a person applies a single approach or tactic to every problem he or she encounters. In software, for example, many of us wanted to use inheritance for everything when we first learned the basics of object-oriented programming. Articles such as Allen Holub's Why Extends is Evil have helped changed this over-arching viewpoint for the better, but I definitely remember trying to force everything into an inheritance hierarchy.

Design patterns are a notorious example of where a developer learns one design pattern (such as Singleton) and everything becomes a problem suitable for that pattern. We'd never want to admit that we always applied the same solution to every problem almost without thinking, but it is actually really easy to do and there is a comfort (hence the pleasure) in doing the familiar.


"Improving" Code that Doesn't Really Need Improvement

As with many of these categories, I am as guilty as the next developer in finding pleasure in improving code even when it realistically probably does not need it. I have seen many situations where one developer changes even the smallest things they don't care for in another's code: curly brace placements might be "fixed," grammar in comments might be "corrected," and even slightly more substantial but still very inconsequential changes get made for things that are often more a matter of taste than of any real significant benefit. I find it mentally painful to realize there is a way to improve my code, but not be allowed to change it because it works fine the way it is. In many of these cases, there is nothing really "wrong" with it, but I have thought of a better way to approach it or new information has helped me to see a new approach. There are times when the improvement is worth the effort, but sometimes the improvement is of such little value that it cannot be rationally justified. This is where the guilty pleasure comes in: it is still tempting to "improve" the code just because one wants it to be improved even if it doesn't need to be.


Playing Favorites

I have seen over and over again examples of developers who criticize certain products that they don't like or can never find any fault whatsoever with products they do like. This is often the case when comparing two implementations of the same functionality. Two otherwise intelligent and skillful developers can become so enamored with a given product or given vendor or can become so hostile towards a given product or given vendor that they cannot see that even their favorite product has disadvantages.

We see this on the web all the time. If someone points out why they don't like a particular product or framework, it is very common for numerous developers to jump all over them for obviously not understanding the product or framework well enough. It is just assumed that everyone who knows anything about the subject should know that this product is inherently good and should like it. To not like a product, in their viewpoint, is to not understand it.

I think the guilty pleasure here is thinking to oneself that I know all the right answers. If someone else doesn't like the product I've been using and evangelizing, it is easy to fall into the trap of thinking that either something is flawed in my own experience and judgment or something is flawed in the experience and judgment of the person critical of my favorite product. The guilty pleasure is thinking that I'm always correct and I always know the best way to do things.


Fame without Fortune

With the recent economic turmoil, it is easier than ever to think of being wealthy as some far-off distant mirage. However, many of the most successful developers that I have known have responded to praise and recognition equally to or even more than they have responded to monetary incentives. I have long felt that the most successful developers tend to be those who are confident without being arrogant. It should come as no surprise, then, that many developers do find pleasure in fame, even if they do not want to acknowledge that pleasure from fame.

There are many examples of this that directly benefit all of us. I have heard several people who are not software developers ask the question, "Why do so many people contribute so much of their own time, creativity, and effort to open source products for which they earn no compensation?" There are several reasons such as needing to include that particular developed product in their commercial product and doing it just for the fun of it, but I also believe that there is a strong motivation to be known for their contribution to the product and to the community.

The need for fame and accolades is evident in blogs such as this one. What benefit do I receive from writing this blog? I do like it when a reader responds via feedback and tells me that a particular tip helped them or saved them significant time. But that alone would probably not be enough to warrant the time I spend on this blog. Although I hate to admit it publicly because it is a guilty pleasure, I am forced to conclude that some of my motivation for writing a blog is the "fame" associated with doing so. (Stating opinions from a soapbox is a close second motivation.)

Any developer who has ever searched for his or her own name on Google, Yahoo, Cuil, or other search engine has shown at least a degree of this particular guilty pleasure. Even people who don't write public blogs, articles, books, or presentations can exhibit this guilty pleasure on a daily basis. The "fame" can be enjoyed even among a small group of fellow developers.


Conclusion

We as software developers certainly have our share of guilty pleasures. Many of these can actually be traced in general terms back to guilty pleasures that all human beings share. However, these general guilty pleasures correspond to concrete and observable behaviors in our work. We may not always want to admit to some of these guilty pleasures, but I think we can at least secretly acknowledge to ourselves that we do have them.

Finally, not all guilty pleasures are necessarily a bad thing. For example, many of the movies, television shows, and musical artists cited as common guilty pleasures actually are truly appreciated by large audiences. Similarly, there are some guilty pleasures in software development that actually have proponents who can and will argue for why these should not be "guilty" pleasures, but instead should bring everyone happiness. Most "guilty pleasures" in the entertainment sense really have more to do with taste and personal preferences than with any measurable or quantifiable value or quality. In some ways, the same could be said for the software development guilty pleasures.


UPDATE (28 November 2008): DrStrangeLug has added a nice software development guilty pleasure to the above list: automating chores that do not need to be automated (implying that they only need to be done once). I definitely find myself falling into this guilty pleasure. I justify it with the same rationale provided by DrStrangeLug: I might be able to use it again some day. As with most of the guilty pleasures above, there is a line between a very good practice (automating routine tasks is an obvious good thing) and spending far more time automating a one-time thing than it would take to do it once. Also, as with the other practices, there can still be some good even from this guilty pleasure: the developer's script or other automation skills get sharpened.