The software development community is easily enamored with pithy names and terms for describing various aspects of our work. I think there are many reasons for this ranging from the noble idea of facilitating communication to the not-so-noble use of terms and acronyms to show off knowledge or belittle someone else for not being "in the know." In this blog entry, I'm going to focus on a few examples that I think were intended to be helpful in aiding communication (and have been). But some of these have been so overly used and abused that I have grown weary of them. Note that in these cases, this was not the fault of the term's originator, but usually was the fault of overzealous individuals who either wanted to prove how "trendy" they were in the software development community or show how much they knew that the next person didn't that they overused or abused the term.
Plain Old Java Object (POJO)
I use the term POJO as my first example for several reasons. First, it demonstrates the power of a carefully chosen term and how useful such creativity can be.
Second, I find that Martin Fowler articulates well many lessons learned from software development experience. When I read his stuff, I usually find myself either thinking, "Wow, that's a really good way to look at it!" or thinking "Wow, that's what I've always believed, so why couldn't I put it like that?" Now, that's not to say that I always agree with everything he says or writes, but I do agree with the lion's share of his work and often at least appreciate his arguments for something even when I don't agree with his end conclusion.
Third, although the coining of the term POJO has accomplished its mission and POJOs and POJO-based frameworks are all the rage these days, it is one of those terms that I can barely stand because it was used so frequently and for such a long period of time by certain individuals to show off what trend setters they were (or thought they were) that I grew sick of hearing it or reading about it. I actually go out of my way to write about "simple Java classes" or use some similar phrase to specifically avoid having to use POJO. It has taken significant will power to use it in this blog entry.
Finally, perhaps the best reason for using POJO in my blog entry on the power of a name is found in Martin Fowler's own description of how the term was coined. In his blog, he points out that people seemed to be missing the substance (the power of "regular objects," a term I much prefer), so he, Rebecca Parsons, and Josh MacKenzie coined the term POJO to help bring more attention to the inherent value of using regular Java objects. Now, there are books with POJO in the title (such as POJOs in Action and Beginning POJOs) and I think we can say, "Mission Accomplished!" Would we be where we are today with EJB 3.0 and other POJO-based software trends if the term POJO had never been created?
Rich Internet Application (RIA)
Related to Ajax, the term RIA has become widely used as well to describe a richer web application experience. If the importance of a name or term is in doubt, RIA provides a reminder of the importance. For example, there is debate now about what RIA should really stand for (such as Rich Internet Application or Rich Interactive Application). Why do people care if the 'I' stands for internet or interactive unless they perceive that there is some importance to a name or term?
Web 2.0 (and now Web 3.0)
While I don't really care for these terms (and I'm not the only one), there is no denying that Web 2.0 has really caught on as a term that describes a somewhat nebulous collection of concepts. Many people seem to "want a piece of Web 2.0" even if they don't know what they really mean by that.
I'm not a fan of the term Web 2.0, so I am less than thrilled that there is already growing interest in and talk about Web 3.0. I did enjoy this entry from A List Apart.
While the term resume-driven development may not have yet had the impact that POJO and Ajax have had, it may hopefully in the long run have even greater impact. The coining of the term resume-driven development (RDD) may lead to developers realizing the importance of realizing their own prejudices and desires when weighing technical alternatives. While resume-driven development certainly seems beneficial to the developer in the short-term, it can be costly for clients and employers and even for the developer in the long-term if things go poorly because of poor RDD-driven decisions.
Vendor-Driven Architecture, like resume-driven development is another pithy term for describing a real and serious problem in software development. Hopefully, this creative term will help us in the software development community to become more aware of these types of issues and do a better job of avoiding them.
Free Speech Versus Free Beer
The differentiation between free speech and free beer when discussing open source and software licenses is an important one that apparently is not always well understood. I have talked to several extremely capable software developers who think that open source means no cost (free beer) when in fact a product's being open source does not necessarily mean its free of cost. On the other hand, there are numerous commercial products that are not open source and are free of any licensing costs.
This may be the oldest of the examples I am focusing on in this blog entry. The object-relational impedance mismatch is the most famous and oldest of this family, but the object-XML impedance mismatch is rapidly becoming a bigger issue with the increased use of XML. The object-relational impedance mismatch has spawned and thus gets prominent mention in most introductions to ORM products such as Hibernate, Java Persistence API (JPA), and TopLink.
Conclusion and Other Significant Names/Terms
Just as the Gang of Four cataloged design patterns in an effort to facilitate learning and communication associated with regularly used software patterns, carefully chosen terms can have the same effect for different software approaches and methodologies. The examples above demonstrate how current and relatively recent coined terms can facilitate progress in the software development community. Sometimes the terms are manufactured by analysts groups or vendors, but they often only gain significant traction when the developers embrace them. Other terms that I have not focused on, but could have included in this blog entry are: Enterprise Service Bus (ESB), Service-Oriented Architecture (SOA), Agile Development, dependency injection, inversion of control, convention over configuration, and configuration by exception.