Significant Software Development Developments of 2012

I have written before (2007, 2008, 2009, 2010, 2011) on my biased perspective of the most significant developments in software development for that year. This post is the 2012 version with all my biases and skewed perspectives freely admitted.

10. Groovy 2.0

Groovy 2.0 have been an important version for Groovy. Groovy 2's arguably most notable new features are its static type checking and static compilation capabilities.

9. Perl Turns 25

Perl celebrated its 25th anniversary in 2012. Love it or loathe it, Perl has definitely become the predominant scripting language, especially in the non-Windows environments. Perl is not my favorite (I'd rather use Groovy, Python, or Ruby), but I find myself needing to use it at times, usually because I'm modifying or using an existing script or set of scripts already written in Perl. Happy Birthday, Perl!

8. Git and GitHub

Git is the trendy choice now in version control and GitHub is equally trendy for hosting code. The post Why Would Anyone use Git in their Enterprise? states, "Git has a cult-like following in the development community." The book Pro Git (2009) is freely available for reading online and can be downloaded as a PDF, mobi, or ePub electronic book.

7. NoSQL and Polyglot Persistence

The NoSQL concept seems to be maturing and moving from unabated hype and hyperbole to understanding when it works well and when it doesn't. In 7 hard truths about the NoSQL revolution, Peter Wayner writes: NoSQL systems are far from a perfect fit and often rub the wrong way. The smartest developers knew this from the beginning. ... the smart NoSQL developers simply noted that NoSQL stood for "Not Only SQL." If the masses misinterpreted the acronym, that was their problem.

Martin Fowler's nosql page states: "The rise of NoSQL databases marks the end of the era of relational database dominance. But NoSQL databases will not become the new dominators. Relational will still be popular, and used in the majority of situations. They, however, will no longer be the automatic choice." With this, Fowler introduced the concept of polyglot persistence (which he mentions was previously coined by Scott Leberknight in 2008) and explicitly compared this to the concept of polyglot programming. If we as a software development community believe that the advantages of using multiple languages in the same application (polyglot programming) are worth the costs, then it follows that we might also determine that the advantages of using multiple data stores within the same application (polyglot persistence) are also worth the costs of doing so.

6. Mobile Development

Mobile development continues to rapidly rise in 2012. The December 2012 write-up on the Tiobe Index states that Objective-C is likely to be the language of the year again in 2012 due to its rapid rise (third in December 2012 behind only C and Java and ahead of C++ and C#). The writers of that summary conclude about language ratings on this index, "In fact it seems that if you are not in the mobile phone market you are losing ground."

Suzanne Kattau's post Mobile development in the year 2012 succinctly summarizes the changes in popular mobile device platforms and operating systems in 2012.

5. Scala (and Typesafe Stack 2.0 with Play and Akka)

I have highlighted Scala multiple times in these year-end review posts, but this is my highest rating of Scala because Scala has seen a tremendous year in 2012. On 23 August 2012, Cameron McKenzie asked, "Is Scala the new Spring framework?" An answer to that question might be implied by the 1 October 2012 announcement that Spring founder Rod Johnson had joined Typesafe's Board of Directors (Johnson left SpringSource in July). Scala provides the intersection of again-trendy functional programming with widely popular and proven object-oriented programming and is part of the increasingly popular movement to languages other than Java on the JVM. It's not difficult to see why it had a big year in 2012.

The Typesafe Blog features a post called Why Learn Scala in 2013? that begins with the statement, "2012 was a big year for the Scala programming language - with monumental releases, adoption by major enterprises and social sites alike and a Scala Days conference that knocked the socks off years past." The post then goes on to list reasons to learn Scala in 2013 with liberal references to other recent positive posts regarding Scala.

Ted Neward has predicted that in 2013 "Typesafe (and their Scala/Akka/Play! stack) will begin to make some serious inroads into the enterprise space, and start to give Groovy/Grails a serious run for their money." I am not calling Play and Akka out in this post as separate significant developments in 2012, but instead lump them together with Scala as part of justifying Scala taking the #5 spot for 2012. There is no question, however, that 2012 was a big year for Akka and Play. The year 2012 saw the release of Typesafe Stack 2.0 along with Play 2.0 and Akka 2.0.

4. Big Data

Big Data was big in 2012. AOL Government has named Big Data its Best of 2012 for the technology category. Geoff Nunberg argues that "'Big Data' Should Be The Word Of The Year." Interest in the statistical computing language R has (not surprisingly) risen along with the surging interest in Big Data.

3. HTML5

2012 was another big year for HTML5. Although HTML5 continued to be evangelized as a standards-friendly favorite of developers, some hard truths (such as performance versus native code) about the current state of HTML5 also became more readily obvious.

That being stated, I think HTML5 still has a very positive future ahead of it. Although it has certainly been over-hyped with emphasis on what it might one day become rather than what it is today, it would also be foolhardy to ignore it or underestimate its usefulness. Two articles that remind us of this are FT exec: HTML5 is not dead and HTML5 myth busting. The article 'HTML5 is ready' say creators of mobile HTML5 Facebook clone talks about attempts to prove HTML5 is ready today from a performance standpoint.

2. Security

Awareness of security holes, risks, and vulnerabilities has been increasing for the past several years largely due to high-profile incidents of lost sensitive data and new legal requirements. However, 2012 seemed to be a bigger year than most in terms of increasing awareness of security requirements and expectations in software architecture and design.

Java seemed to be particularly hard hit by bad security news in 2012. Articles and posts that provide examples of this include 1 Billion computers at risk from Java exploit, Oracle's Java Security Woes Mount As Researchers Spot A Bug In Its Critical Bug Fix, Java Vulnerability Affects 1 Billion Plug-ins, Another Week, Another Java Security Issue Found, Oracle and Apple Struggle to Deal with Java Security Issues, and Java still has a crucial role to play—despite security risks.

The article Oracle to stop patching Java 6 in February 2013 suggests that users of Java should upgrade to Java 7 before February 2013 when Oracle will supply the last publicly available security patch to Java SE 6 outside of an Oracle support plan. Another article is called Oracle's Java security update lacking, experts say.

1. Cloud Computing

It seemed like everybody wanted a cloud in 2012 even if they didn't really need one. Archana Venkatraman put it this way, "2012 was the year cloud computing hit the mainstream." Steve Cerocke stated, "2012 will go down as the year of cloud computing." Other articles and posts on the biggest cloud stories of 2012 include The 10 Biggest Cloud Stories Of 2012 and Top five cloud computing news stories in 2012.

Cloud Computing is in the sweet spot many trendy technologies and approaches go through when enthusiasm is much greater than negativism. Charles Babcock's Cloud Computing: Best And Worst News Of 2012 is more interesting to me than many cloud-focused publications because it highlights the good and the bad of cloud computing in 2012.

Honorable Mention

I couldn't fit everything that interested me about software development in 2012 into the Top Ten. Here are some others that barely missed my cut.

C

As mentioned earlier, the C programming language appears headed for #1 on the Tiobe Index for 2012. One of programming's most senior languages is also one of its most popular. When one considers that numerous other languages are themselves built on C and when one considers that many languages strive for C-like syntax, the power and influence of C is better appreciated. C's popularity has remained strong for years and 2012 was another very strong year for C.

Another piece of evidence arguing C's case is the late 2012 O'Reilly publication of Ben Klemens's book 21st Century C: C Tips from the New School. The author discusses this book and C today in the O'Reilly post New school C.

Although I have not written C code for several years now, I've always had a fondness for the language. It was the language I used predominately in college (with Pascal and C++ being the other languages I used to a less degree) and I wrote the code for my electrical engineering capstone project in C. I remember (now fondly) spending almost an entire Saturday on one of my first C assignments fighting a bug to only realize that it was not working because I was using the assignment operator (=) rather than the equality operator (==). This lesson served me well as I learned other languages in terms of both what it important to differentiate and in terms of how to better debug programs even when a debugger is not readily available. I think my C experience grounded me well for later professional development with C++ and Java.

Gradle 1.x

Using an expressive programming language rather than XML or archaic make syntax to build software seems like an obviously beneficial thing to do. However, make, Ant, and Maven have continued to dominate in this area, but Groovy-based Gradle shows early signs of providing the alternative we've all been looking for. Gradle still has a long way to go in terms of acceptance and popularity and there are many other build systems with some of Gradle's ideals that have failed, but Gradle did seem to capture significant attention in 2012 and can hopefully build upon that in future years. Gradle 1.0 was formally released in June 2012 and Gradle 1.3 was released in November 2012.

DevOps

Among others, Scott Ambler predicted that "DevOps will become the new IT buzzword" in 2012. If it is not "the" buzzword of 2012, it is not for a lack of trying on the DevOps evangelists' part. The DevOps movement continued to gain momentum in 2012. The DZone DevOps Zone sees one or more posts on the subject added each day. The only reason this did not make it into my Top Ten is that I still don't see "Typical Everyday Coder" talking about it when I am away from the blogosphere talking to in-the-trenches developers.

Amber's concluding paragraph begins with this prediction, "Granted, there’s likely going to be a lot of talk and little action within most organizations due to the actual scope of DevOps, but a few years from now, we’ll look back on 2012 as the year when DevOps really started to take off." Only time will tell. There continue to be posts trying to explain what exactly DevOps is.

Departures of Noteworthy Development Personnel

There were some separations of key developers from their long-time organizations in 2012. As mentioned previously, Spring Framework founder Rod Johnson left VMWare/SpringSource (and ultimately ended up on the Board of Directors for Scala company Typesafe). Josh Bloch, perhaps still best known for his work at Sun on the JDK and for writing Effective Java, left Google in 2012 after working there for eight years.

Resurgence of Widely Popular but Aged Java Frameworks

Two very popular long-in-the-tooth Java-based frameworks saw a resurgence in 2012. Tomek Kaczanowski recently posted JUnit Strikes Back, in which he cites several pieces of evidence indicating a resurgence in JUnit, arguably the most commonly used testing framework in Java (and, in many ways, the inspiration for numerous other nUnit-based unit testing frameworks). Christian Grobmeier's recent post The new log4j 2.0 talks about many benefits of Log4j2 and how it can be used with more recently popular logging frameworks such as SLF4J and even Apache Commons Logging.

Electronic Books (E-books)

Electronic books (ebooks) are becoming widely popular in general, but also specifically within software development books. This is not surprising because e-books provide many general benefits, but also have benefits particular to software development. In particular, it is nice to be able to electronically search for terms (overcoming the poor index problem common to many printed programming books). Other advantages include the ability to have the book on laptops, mobile devices, e-readers, and other portable devices. This not only makes a particular book readily available, but makes it easy to carry many books on many different technical subjects with one on travel. It is also less likely for the electronic book to be "borrowed" unknowingly by others or turn up missing.

Perhaps the biggest advantage of electronic books is cost. It is fairly well known that technical books are generally not big profit makers for publishers. However, with printing and distribution costs being a significant portion of traditional publication costs, e-books make it easier to publishers to price these books at a lower cost than the printed equivalent.

The reduced cost to the publisher for an electronic book can be passed onto the consumer. I recently took advantage of an offer from Packt Publishing to purchase a total of eight of their books as electronic books for a total price of $40. Given that a single printed programming book can cost $40 or more, this was a bargain. I have also blogged on other good deals on e-books provided by other technical publishers such as O'Reilly and Manning.

I have especially appreciated the Manning Early Access Program (MEAP). This program is only viable thanks to electronic books and allows readers to read a book as it is developed. Because technologies change so quickly, it is often helpful to get access to even portions of these books as quickly as possible.

Finally, another advantage of e-books is their ultimate disposal. In reality, they take up such a small portion of even an old-fashioned CD or DVD, that I can usually dig up a copy if I want to. However, I can remove them from my electronic devices when I no longer need them and need the space. There are no environmental or logistic concerns about their disposal. This is important because these books do tend to get outdated quickly and sometimes an outdated programming book is worse than having no book at all because it can be very misleading.

PhoneGap / Cordova

Given the popularity of mobile development and HTML5 in 2012, it's not surprising that PhoneGap and Cordova had big years in 2011/2012. In the web versus native debate, one of the advantages of web is the portability of web apps across multiple devices. The PhoneGap/Cordova approach brings some of this benefit for writing code but maintains some of the performance advantages of running native applications.

Objective-C

Objective-C looks to win the Tiobe Index language of the year again in 2012. This is yet another indicator of mobile development prevalence as Objective-C's popularity is almost exclusively tied to iPhone/iPad development, though Objective-C's history is closely coupled with the NeXT workstations and even has been called an inspiration for Java (advertised as quoted by Patrick Naughton) instead of C++.

Kotlin

For several years now, it has been trendy for the "cool kids" to post feedback messages on articles or blogs about Java features proclaiming that Groovy or Scala does anything covered in that blog post or article better than Java does it. Many of the "cool kids" (or maybe different "cool kids" with the same modus operandi) now seem to be doing the same on Scala blog posts and articles, advocating the advantages of Kotlin over Scala.

As Scala and Groovy still lag Java in terms of overall popularity and usage, Kotlin lags both Groovy and Scala in terms of adoption at this point. However, there are definitely some characteristics of Kotlin in its favor. First, the Kotlin web page describes the language as, "a statically typed programming language that compiles to JVM byte codes and JavaScript." I could definitely see how "statically typed" and "compiles ... to JavaScript" would be endearing to developers who must write JavaScript but prefer static compilation. Andrey Breslav, Kotlin Project Lead, believes that static languages compiling to "typed JavaScript" will be a major development of 2013 and he cites Dart and TypeScript as other examples of this. Being able to run on the JVM can also be an advantage, though this is no different than Groovy or Scala.

One major positive for Kotlin is its sponsor: JetBrains. It is likely that their IDE, IntelliJ IDEA, will provide elegant support for the Kotlin language. This is also a sponsor/owner with the resources (monetary and people) to improve chances for success. Because JetBrains is "planning to roll out a beta of Kotlin and start using it extensively in production," they are more likely to continue investing resources in this new language.

There was no way I could justify to myself putting Kotlin in my top ten for 2012, but once it is released for production use, it is possible that Kotlin may make another year's Top Ten list if it is widely adopted.

Ceylon

Kotlin isn't the only up-and-coming static language for the JVM; Ceylon is also relatively young in this space. I wrote about the JavaOne 2012 presentation Introduction to Ceylon and that post provides brief overview and description information.

The first milestone of Ceylon IDE (Eclipse plug-in) was released in early 2012 and was followed in March with the release of Ceylon M2 ("Minitel"). This was followed by the Ceylon M3 ("V2000") release in June and Ceylon M4 ("Analytical Engine") in October.

The newer JVM-friendly languages with the seeming best chances of long-term viability are those with strong sponsors: Groovy has SpringSource, Scala has TypeSafe, Kotlin has JetBrains, and Ceylon has RedHat.

End of Oracle/Google Android Lawsuit

The lawsuit between Oracle and Google over Android seems to have, for the most part, concluded in 2012. There still seems to be bad blood between the two companies, but the settlement of this probably allows for continued success of the Android platform and potentially for collaboration at some future point between the two companies on Java. It will be interesting to see if Google allows its employees to submit abstracts to JavaOne 2013.

Everyone a Programmer

When HTML first started to expand across the universities and colleges in the early-to-mid 1990s, it seemed that everyone I knew was learning HTML. Most of us were "learning" it by copying other peoples' HTML source and editing it for our own use. Of course, everything then was static and fairly easy to pick up. It probably also skewed my perspective that I was majoring in electrical engineering with an emphasis in computer science and so was around people who had a tendency to adopt and use new technology. Perhaps for the first time since then, I have felt that there is an ever-growing interest in pushing everyone to learn how to program at a certain level. I don't need to provide any supporting points for this because I can instead reference Joab Jackson's 2012: The year that coding became de rigueur. Not only does this post enumerate several examples of the debate about whether everyone should learn programming, but it also makes cool use of "de rigueur" in its title.

Java

I did not include Java itself in my Top Ten in 2012. Perhaps this is an indication that I too felt that 2012 was a slow year for Java (and agree that this is not necessarily a bad thing). That being stated, Martijn Verburg has listed some "personal highlights of the year" in the world of Java in 2012 in What will 2013 bring? Developers place their bets. These include the JVM's entry into the cloud, Java/JVM community growth, OpenJDK, Java EE 7, and Mechanical Sympathy.

It's a small thing in many ways, but I think James Gosling returning to JavaOne and throwing out t-shirts was symbolic of a strengthening resurgence among an already strong Java development community.

Jelastic

Java on the cloud in general had a big year in 2012. Jelastic had a particularly big year. The screen snapshot below is from an e-mail sent out by Jelastic COO Dmitry Sotnikov.

Jelastic was prominently mentioned at JavaOne 2012 multiple times. Some of these mentions were due to winning the Duke's Choice Award for 2012. Other mentions resulted from James Gosling's positive review of his use of Jelastic. As I blogged on earlier, Gosling described himself as "a real Jelastic fan" at the JavaOne 2012 Community Keynote.

Linux-based ARM Devices

Oracle announced release of a Linux ARM JDK in 2012. The ability to run even JavaFX on Linux ARM devices provides evidence of Oracle's interest in supporting Linux ARM devices. Given that Oracle is well-known for investing in areas where returns are often great, it follows that perhaps Oracle sees great potential for the Linux ARM devices in the future. An interesting article that looks into this is Java 8 on ARM: Oracle's new shot against Android?

One couldn't go to a keynote presentation at JavaOne 2012 without hearing about one very trendy Linux ARM Device, the Rasperry Pi. Similarly, the BeagleBoard and PandaBoard have also become very popular.

Improving Job Market for Software Developers

2012 seemed to be a good year for those with careers in software development and this seems likely to continue. CNN Money ranked software developer as #9 in its Best Jobs in America story (software architect was #3). For example, Lauren Hepler has written that Software developers top 2013 job projection and cites a Forbes slides-based presentation.

Perhaps more importantly than these stories are my anecdotal observations of a surging market for software developers. I have seen an uptake in number of unsolicited employment queries from potential employers and clients. I am also seeing an increase in billboard advertising for developers, especially in areas of the United States with high concentrations of software development. This improving job market might be one of many reasons for increasing interest in programming in general.

Other Resources

There are other posts of potential interest. Katherine Slattery's Takeaways from the Top Development News Stories of 2012 talks about the Node.js "hype cycle," open source hardware, native apps versus HTML5 apps, and the "'learn to code' craze."

Ted Neward's annual predictions (for 2013 in this case) and review of his prior year (2012 in this) predictions is an interesting read.

Conclusion

2012 was another big year in software development across many different areas and types of development. Many of the themes discussed in this post overlap and are somehow associated with mobile development, cloud computing, and greater availability of data.

$5 E-books at Packt

Packt Publishing is offering $5 (USD) e-books when two or more are purchased through 3 January 2013. Their Stock Your Reader for Christmas page contains the details and I have included a snapshot of that here.

I've had my eye on a few of Packt's books, but wasn't sure how much time I'd have to read them. However, at $5 a piece, it was an easy decision to purchase them, even if I'm only able to browse them and read the most interesting portions. To take advantage of the deal, two of more e-books must be purchased. Fortunately, all of the Packt Publishing books appear to be part of this deal rather than a limited selection. As the next two screen snapshots indicate, I was able to purchase six e-books of interest to me for $30 (USD).

I don't know how good each of these books is, but at $5 per book, it wasn't much of a gamble. As the screen snapshots above indicate, I ended up purchasing Play Framework Cookbook (August 2011), HTML5 Mobile Development Cookbook (February 2012), PhoneGap Beginner's Guide (September 2011), EJB 3.1 Cookbook (June 2011), Apache Maven 3 Cookbook (August 2011), and Java EE 6 with GlassFish 3 Application Server (July 2010). I am tempted to go back and purchase the PhoneGap Mobile Application Development Cookbook (October 2012) e-book and, because you need at least two for the $5 each deal, I may be "forced" to purchase HTML5 Canvas Cookbook (November 2011) as well. For the typical price of a single book, I am able to get 6 to 8 books in a variety of subjects with this offer.

When Premature Optimization Isn't

Earlier this month, I decided I wanted to write a post on not all optimization being premature optimization after hearing more than one developer use this mantra as an excuse for not making a better decision in the same week. Bozhidar Bozhanov beat me to it with his post Not All Optimization Is Premature, which makes some excellent but different points than I had planned to make in postulating that there is nothing wrong in early optimizing "if neither readability nor maintainability are damaged and the time taken is negligible."

Bozhanov's post reminded me that I wanted to write this post. I use this post to provide additional examples and support to backup my claims that too many in our community have allowed "avoid premature optimization" to become a "bumper sticker practice." In my opinion, some developers have taken the appropriate advice to "avoid premature optimization" out of context or do not want to spend the time and effort to really think about the reasons behind this statement. It may seem easier to blindly apply it to all situations, but that is just as dangerous as prematurely optimizing.

Good Design is Not Premature Optimization

I like Rod Johnson's differentiation between "design" and "code optimization" in his book Expert One-on-One J2EE Design and Development (2002). Perhaps the most common situations in which I have seen developers make bad decisions under the pretense of "avoiding premature optimization" is making bad architecture or design choices. The incident earlier this month that prompted me to want to write this post was a developer's assertion that we should not design our services to be coarser grained than he wanted because that was premature optimization and his idea of making numerous successive calls on the same service was "easiest" to implement. In my mind, this developer was mistaking the valid warning about not prematurely optimizing code as an excuse to not consider an appropriate design that might require a barely noticeable amount of extra effort.

In his differentiation between design and code optimization, Johnson highlighted, "Minimize the need for optimization by heading off problems with good design." In that same section he warns against "code optimization" for four main reasons: "optimization is hard" ("few things in programming are harder than optimizing existing code"), "most optimization is pointless," "optimization causes many bugs," and "inappropriate optimization may reduce maintainability forever." Johnson states (and I agree), "There is no conflict between designing for performance and maintainability, but optimization may be more problematic."

Applying Appropriate Language Practices is Not Premature Optimization

Most programming languages I'm familiar with often offer multiple ways to accomplish the same thing. In many cases, one of the alternatives has well-known advantages. In such cases, is it really premature optimization to use the better performing alternative? For example, if I'm writing Java code to append characters onto a String within a loop, why would I ever do this with a Java String instead of StringBuilder? Use of StringBuilder is not much different in terms of maintainability or readability for even a relatively new Java developer and there is a known performance benefit that requires no profiling to recognize. It seems silly to write it with String in the name of "avoiding premature optimization" and only change it to StringBuilder when the profiler shows it's a performance issue. That being stated, it would be just as silly to use a StringBuilder for simple concatenations outside of a loop "just in case" that code was ever placed within a loop.

Similarly, it's not "premature optimization" to write a conditional such that the most likely condition is encountered first as long as doing so does not make the code confusing. Another example is the common use of short circuit evaluation in conditionals that can be effective without being premature optimization. Finally, there are cases where certain data structures or collections are more likely to be appropriate than others for a given operation or set of expected operations.

Writing Cleaner Code is Not Premature Optimization

Some developers might confuse more "efficient" (cleaner) source code with premature optimization. Optimizing source code for readability and maintainability (such as in refactoring or carefully crafting original code) has nothing to do with Knuth's original quote. Writing cleaner code often leads to better performance, but this does not mean writing cleaner code is a form of premature optimization.

Others' Thoughts on Misunderstanding of Premature Optimization

Besides the Not All Optimization Is Premature post, other posts on the misapplication of the "avoid premature optimization" mantra include Joe Duffy's The 'premature optimization is evil' myth and 'Avoid Premature Optimization' Does Not Mean 'Write Dumb Code'.

Duffy puts it so well that I'll quote him directly here:

I have heard the "premature optimization is the root of all evil" statement used by programmers of varying experience at every stage of the software lifecycle, to defend all sorts of choices, ranging from poor architectures, to gratuitous memory allocations, to inappropriate choices of data structures and algorithms, to complete disregard for variable latency in latency-sensitive situations, among others. Mostly this quip is used defend sloppy decision-making, or to justify the indefinite deferral of decision-making. In other words, laziness.

The James Hague post points out one of the signs of potentially having crossed into premature optimization: "The warning sign is when you start sacrificing clarity and reliability while chasing some vague notion of performance." Hague also writes, "What's often missed in these discussions is that the advice to 'avoid premature optimization' is not the same thing as 'write dumb code.'" I like this last sentence because I believe that just as some developers have adulterated the agile concept to mean (to them) "no documentation," some developers have adulterated the sound advice to "avoid premature optimization" to mean (to them) "blindly write code."

Premature Optimization is a Real Problem

Premature optimization is a problem we developers must guard against. As Johnson states in the previously cited book, "Few things in programming are harder than optimizing existing code. Unfortunately, this is why optimization is uniquely satisfying to any programmer's ego. The problem is that the resources devoted to such optimization may well be wasted." There makings examples of where premature optimization wastes significant resources and in some cases even makes things perform worse. There is indeed a reason that the well-regarded Knuth wrote that "premature optimization is the root of all evil." I'm not saying that premature optimization doesn't exist or that it's not harmful. I'm just saying that avoiding this admitted dysfunctional behavior is often used an an excuse to avoid thinking or to avoid implementing sound decisions.

Conclusion

Like pithy bumper stickers on cars that naively boil down complex issues to a few clever and catchy words, use of "avoid premature optimization" is often used much more broadly than it was intended. Even the best of recommended practices can cause more harm than benefit when applied improperly and the misuse of "avoid premature optimization" is one of the best examples of this. I have seen the high cost paid in maintainability, readability, and even in performance when supposed "optimization" was implemented too early and at the expense of readability and maintainability for no measurable benefit. However, just as high of a cost can be incurred by blindly using "avoid premature optimization" as an excuse to avoid designing and writing better performing software. "Avoiding premature optimization" is not an excuse to stop thinking.

Design Patterns: Mogwai or Gremlins?

The 1994 book Design Patterns: Elements of Reusable Object-Oriented Software introduced many software developers to the concept of "a catalog of simple and succinct solutions to commonly occurring design problems" that nearly every object-oriented software developer knows of today as "design patterns." Like most technical concepts (whether real or hype or somewhere in between), "design patterns" seemed to go through the normal stages of acceptance, rising rapidly from new idea to the prevalent way of thinking. As is always the case, this rapid rise in popularity led to backlash as design patterns were overused, abused, and otherwise used inappropriately. Today, design patterns seem to have become accepted as a useful tool when used correctly, but are generally recognized as dangerous in the wrong hands.

I have generally avoided devoting an entire blog post to a discussion of the good, the bad, and the ugly of use of design patterns, but a fellow software developer recently made up an analogy related to his observations of the use and misuse of design patterns that motivated me to write this post. Andy pointed out that there seems to be a tendency among some software developers to take an innocent and well-intentioned design pattern and turn it to evil, like turning a Mogwai like Gizmo into a Gremlin. In this post, I look in more detail at why this is a particularly fitting movie-themed analogy for turning effective use of design patterns into misuse and abuse of design patterns.

The 1984 movie Gremlins begins with an inventor and father in Chinatown purchasing a Mogwai. Mr. Wing, the owner of the store, does not want to sell the Mogwai to the inventor/father because "with Mogwai comes much responsibility." However, Mr. Wing's grandson sneakily sells the Mogwai to the inventor/father while warning him of three important things to be aware of related to care of the Mogwai. These three things are:

1. "Keep him out of the light. He hates bright light, especially sunlight. It will kill him."
2. "Keep him away from water. Don't get him wet."
3. "But the most important rule, the one you can never forget, no matter how much he cries or how much he begs never, never feed him after midnight."

The appropriate use of design patterns is not affected by bright light, water, or eating after midnight, but the effects of not taking care when applying design patterns can have effects similar to not taking care of Mogwai properly.

Rapidly Spawning Design Patterns

When Mogwai or Gremlins get wet, spontaneous reproduction of more Mogwai or Gremlins occurs. The effect can be very similar for developers with design patterns. It is easy for a developer new to design patterns (or a developer who is excited about a new design pattern that he or she has recently learned) to apply too many design patterns to the same problem. If design patterns are good, more of them must be better. It is similarly easily for developers to fall into the trap of applying the same favorite design pattern to too many different, diverse, and unrelated problems (Maslow's Hammer).

Design Patterns Turned Evil

The Mogwai turned into mischievous Gremlins if they ate after midnight. Similarly, design patterns can be more evil than good if used inappropriately. A misapplied design pattern can obfuscate the intention of the code. Several design patterns used together can obscure the intent as well. Design patterns that are meant to facilitate better design can and often do lead to worse design when not used carefully. What is a design pattern in one situation might be an anti-pattern in a different situation.

One of the benefits of cataloging the common design principles as patterns is the ability to aid communication among developers and designers. However, design patterns can have the exact opposite effect (hindering understanding and communication) when misapplied or overused. I have also seen the case when a developer insists he or she is using a particular design pattern when he or she is really using a totally different design pattern or even an anti-pattern. In such cases, use of "design pattern" terminology also confuses rather than clarifying.

Well-Intentioned But Ill-Conceived

These problems most commonly arise when developers apply the design patterns because they believe they should rather than because they truly understand their value in a particular situation. Rather than applying the same design pattern to every problem or shoe-horning a design pattern into a situation in which it does not fit well, the developer needs to understand the advantages and objectives of different design patterns, along with trade-offs associated with the design patterns, to make an informed decision about application of design patterns.

Effective Use of Design Patterns

It seems to me that the best use of design patterns occurs when a developer applies them naturally based on experience when need is observed rather than forcing their use. After all, when the Gang of Four compiled their book on design patterns, they were cataloging existing design patterns that developers had been using already. Indeed, some of the patterns covered in their book became so popular that they were incorporated into Java language syntax and into other newer languages. For example, Java provided the interface (which aids many of the design patterns covered in the original design patterns book) and newer languages such as Scala and Groovy have added their own pattern implementations.

Use of Design Patterns: Gizmo or Gremlin?

When used properly, design patterns are attractive and desirable just as Gizmo the Mogwai is a desirable pet. However, when used inappropriately or applied without appropriate care and consideration, design patterns can turn into Gremlins, wreaking havoc on one's code base and hindering the ability to understand and maintain one's design. Note that the design patterns themselves are not necessarily the problem, but rather the people entrusted with proper use of design patterns determine whether they maintain desirable like Gizmo or undesirable like the Gremlins.

Packt Publishing's 1000th Title: Surprise Gifts

Packt Publishing published its first book in 2004 and is about to publish its 1000th book. Along the way, Packt Publishing has donated a portion of revenue to the open source projects covered by its books. As part of their celebration of publishing their 1000th title, Packt Publishing has a "surprise gift" for anyone who has registered with them or has an account with them on 30 September 2012.

This is the information Packt Publishing provided to me related to this celebration:

To celebrate this event with our readers, we'd be gifting them with not one but two assured surprises which would be revealed to them by the 30th of September, 2012. Anyone who is already registered or signs up for a free Packt account before 30th September 2012 is guaranteed a surprise gift.

I have received electronic copies of Packt Publishing books in the past as part of book reviews. The books I reviewed are JBoss AS 7 Configuration, Deployment and Administration, Java EE 6 Cookbook for Securing, Tuning, and Extending Enterprise Applications, and Java EE 6 Development with NetBeans 7. In addition, I have purchased three electronic books from Packt Publishing (Groovy for Domain-Specific Languages, Learning jQuery, and Java 7 New Features Cookbook).

Packt Publishing has offered me an electronic book for promoting this celebration event and I am having a difficult time choosing from many selections that look interesting including Grails 1.1 Web Application Development, GlassFish Security, Java 7 Concurrency Cookbook, Akka Essentials, and Java EE 6 with GlassFish 3 Application Server.

The Software Developer's Pensieve

Fictional stories (especially science fiction) are full of gadgets and other items that I wish were available to me today. One of the fictional items I would most like to have is the pensieve described in Harry Potter books and shown in Harry Potter movies. This pensieve allows the participant to save his or her memories so that he or she can review them again from a third-person perspective with the clarity of being back in that memory again. Although we don't have pensieves in our world, there are some relatively recent innovations that do bring us closer to it. I look at some of these in this post and describe why they are useful to the software developer trying to recall why a particular decision was made or even what the decision was.

Most serious engineers have learned to appreciate a medium for saving thoughts, decisions, and results of experiments or discussions for later reference. This is no less valuable for the software developer.

Personal Blogs

One of my motivations for writing this software development-oriented blog is as a form of a pensieve for observations and lessons learned related to software development. My JavaWorld-syndicated version of this blog includes this very motivation in its description: "This blog is intended to provide information to help other developers facing the same issues as well as providing me a method to document things in a well-known location for my own future reference." Because of their publicly available online nature, personal blogs are easy to access from almost anywhere.

Blogger added a new Gadget a while back that allows me to provide a powerful Google Search-backed search of my blog's content. This makes it easier than ever to find something I know I wrote about it when I need certain details that I've forgotten. Re-reading one of my posts or the example code in one of my posts often brings back many other details related to the post.

E-mail

With modern e-mail systems offering large amounts of data storage space, it is easier than ever to store information in my mail storage. E-mail may be preferable to a personal blog post if it seems only individually interesting rather than generally interesting or if it contains details that are not appropriate for public consumption. E-mail tends to be easily searchable as well. E-mail is really more of a powerful communication tool than a pensieve substitute, but it can serve that function to a lesser degree.

Using e-mail as a pensieve has its drawbacks. Changing e-mail systems can be problematic if previous experience is only available in the older e-mail system. E-mail can also be more temporary in nature in some cases where aggressive e-mail purging occurs. A feature of e-mail that can be both an advantage and a disadvantage is the nature of the multi-way communication that occurs in a given e-mail thread. A particular thread can be rich with details leading to a design decision or other important details, but these same important details can also be difficult to glean from the verbosity of some e-mail threads. Splitting e-mail threads can also make it difficult to confidently reconstruct a particular decision or discussion.

Online Collaborative Tools (Google Docs)

I have been using Google Docs in a variety of work-related and personal-related areas and really enjoy the collaborative nature of these products. Having others be able to instantly see my changes and my being able to instantly see their changes is very useful. In addition, the ability to see the "latest and greatest" anywhere that I have online access is liberating because I don't need to worry about having access to the productivity software products on any computers I'm using and, even better, I don't need to worry about ensuring that the latest version of the file is available on some medium.

These online tools have many of the advantages of the Wiki (discussed next), but tend to be useful for smaller groups of people where the "overhead" of the Wiki does not seem justifiable or where the people involved are more comfortable working with productivity software such as spreadsheets, presentations, and documents than they are with Wiki text and HTML.

Wiki

Most software developers can quickly and easily pick up the basics of any given Wiki product and quickly start using it effectively. Wikis seem to be a natural fit for software developers and in many ways feel to me like an extension of the approach I used years ago of creating static web pages to store information for others' reference and for my own personal future reference. Wikis are easier to add content to than static web pages and are far easier for multiple authors to edit. One of the major advantages of Wikis over static web pages and even over the online collaborative tools is the built-in versioning. It is often useful to see a previous version of a particular Wiki entry. Versioned Wiki pages are a sort of versioned Pensieve, allowing the developer to determine what (s)he or others was thinking or deciding at any given point in time.

Another advantage of the Wiki is the ability to easily link to other HTML material such as Javadoc, online product documentation, bug or defect reports, and related blogs and articles.

Conclusion

We have many fine tools available to us today for recording important decisions and lessons learned. I have seen these technologies improve dramatically during my career, but the degree of improvement is even larger when compared to the documentation tools described in The Mythical Man-Month. It is exciting to think about what the future holds in store for improving our ability to persist our memories in a fashion that allows us to easily recall them and feel as if we're experiencing again a moment from our past.

The Developer/Non-Developer Impedance Mismatch

Most software developers have probably heard of and even had experiences with the object-relational impedance mismatch (often addressed with ORM tools), the object-XML impedance mismatch (often addressed with OXM tools), and even the developer-DBA impedance mismatch. I don't believe that these impedance mismatches are as difficult as they are sometimes made out to be, but for those wishing to mitigate them, we have tools such as Java Persistence API implementations and JDO implementations for dealing with the object-relational mismatch (and some of the developer-DBA impedance mismatch) and similarly have approaches such as JAXB, XMLBeans, JiBX and Apache Commons Digester for dealing with the object-XML mismatch (and .NET's LINQ deals with both ORM and OXM mismatches). At this point in my career, I believe the developer/non-developer impedance mismatch is perhaps the most frustrating impedance mismatch I have run into.

Although there are numerous tools and approaches for dealing with these other types of impedance mismatches, it seems we're woefully short on similarly powerful tools, approaches, and proven practices (my new preferred term for what I think "best practices" was originally intended to mean) for dealing with the developer/non-developer mismatch. In this post, I look at some of the most common areas of developer/non-developer mismatch and speculate as to why they occur and what can be done to address these specific areas of developer/non-developer impedance mismatch.

Sadly, we have much less control over the developer/non-developer impedance mismatch than we do over object-relational or object-XML impedance mismatches. Although in general things like improved communication and education can help, these answers are not as tangible as the ones we're used to for dealing with other types of software development impedance mismatches. As difficult as it is to deal with the developer/non-developer impedance mismatch, we must do so because there are numerous significant stakeholders in the software development process that are not necessarily developers (managers, clients, testers, customers, business analysts, sales people, and more).

DRY Principle / Modularity

Almost to a fault, developers have generally adopted (at least in a theory if not always in practice) the DRY (Don't Repeat Yourself) principles coined in the often-referenced book The Pragmatic Programmer: From Journeyman to Master. Although the term was coined in this 1999 book, the practice had been one that developers for decades had understood to some degree. Regardless of native spoken language or favorite programming language, developers today widely recognize virtues of some degree of DRY-ness. There may be some debate as to what level this should be taken (I've seen it taken past the point of common sense), but most of us agree with the perils of repeated documentation at different levels of the software product or of repeated code (copy-and-paste development).

Benjamin Denckla, in the post "Faith in DRY; no hope for software," writes, "Today we produce software through a laborious, undisciplined process that combines the low quality work of many with the heroic high quality work of a few. ... Not enough people believe in DRY and other good practices like it." I believe this is especially true when one considers the non-developers involved in a software development project. In my experience, the developers generally do see the value in some significant degree of DRY, but non-developer stakeholders see little value in DRY principles.

For purposes of this discussion, I'm including modularity in what I'm calling DRY practices. Most developers know there are numerous reasons to not copy-and-paste the same code into multiple places. For many decades, developers have known to place reusable code in methods, functions, modules, or other constructs that allow the same code to be used in multiple contexts and situations. It doesn't take long for this to become second nature to the experienced developer. Sadly, many non-developers seem to not acknowledge the risks and problems associated with redundant information copied from place to place or believe these risks and problems are more theoretical than real. Although it may not be code we're talking about when we discuss non-developers (it may be documentation, requirements, specifications, test procedures, or a host of other non-code things), the principle still applies: reproducing anything in multiple places leads to problems down the road in terms of maintenance and keeping the many versions synchronized with the latest and greatest. Developers seem to almost intrinsically "get it," but I see it less well received from many non-developers.

Readable and Maintainable Code

Many new software developers and even more non-developers do not recognize the value of code that is more readable and more maintainable. Perhaps the best experience a young developer can have is to maintain and reuse someone else's code. Doing so helps a young developer to recognize the value of writing code as cleanly as possible. Because non-developers never really get this experience, it is not surprising that they don't value cleanness, maintainability, and readability to the same degree as the experienced developer. Many legitimate cries for time to refactor a code base to improve its future maintainability and readability are ignored or promptly dismissed because such efforts' value is not obvious to those making the decisions.

Overbearing Processes and Management Decisions

I have occasionally seen non-developers in management roles trying to coerce developers into very narrow and specific behaviors that they (the managers) believe is best (or worse, that they perceive as giving them the power). These folks rarely have the experience to know the full ramifications of their decisions. Good managers listen to their developers (particularly those with significant experience and in technical leadership roles) before pushing out every "good idea" they have. Experienced developers usually know what it takes to write high-quality software, but it almost takes another experienced software developer to appreciate what they argue for. Alternatively, a manager lacking software development experience can sometimes make better decisions by choosing an experienced developer that he or she trusts with technical decisions. The best non-technical managers recognize their own lack of technical knowledge and work with a trusted technical expert to make good decisions.

Bean Counting and Pencil Pushing

Most software development is done as part of a business venture and it is often inevitable that some degree of bean counting and pencil-pushing will be required.. Clients or consumers directly or indirectly finance the creation of software. It can be difficult for developers to recognize and appreciate the legitimate management and metrics collection that goes on during these business-oriented phases. It can be equally difficult for managers and other non-developers to understand that some things are more subtle than the apparent "bottom line." Non-developers may over-emphasize short-term "bottom line" considerations at the expense of long-term quality and maintainability of the product while developers may overly neglect bottom line considerations and create software products that require too much time and investment to justify their likely return on investment.

The bean counter wants nothing more than to be able to count things like beans. He or she wants to use lines of code, number of defects in various states, number of requirements, and so forth to feel like he or she has a handle on the software development progress being made. It doesn't really matter that these are not created equally and should not be counted as if they are equal.

Battle for Control

It seems to be human nature and common in many relationships between humans to have battles for control. Tension can increase in the relationship between developers and non-developers as each group tries to exert control. Many non-developers, especially if they don't understand development or coding well, resent not being able to control what is added to the baseline. Many developers resent being told what they can put into the baseline, especially when they strongly believe that the non-developer is making arbitrary calls while lacking sufficient knowledge and background to make that call.

The battle for control can become very onerous when both sides are "know-it-alls." When either side is convinced of its superiority, it can be very difficult to get either to budge. Developers often feel their experience and skillset best qualifies them for making all software decisions while clients, managers, and others often feel their position does the same for them.

Coding: Job for a Craftsman or for a Technician?

Good software development managers recognize that software development can be a highly creative and challenging effort and requires skilled people who take pride in their work. Other not-so-good software managers consider software development to be a technician's job. To them, the software developer is not much more than a typist who speaks a programming language. To these managers, a good enough set of requirements and high-level design should and can be implemented by the lowest paid software developers. Some software development is easier than other software development, but the simple technician work has been largely replaced by automation and code generation at this point.

Perhaps the perceptions of technician versus craftsman explain why non-developers tend to be more likely to believe that all developers are plug-and-play while experienced developers realize that there can be a wide disparity in skillsets and knowledge between any two developers.

Appreciation of Software Development Nuances and Subtleties

It usually does not take long for a developer to realize that relatively little in software development is cut and dry. Software development often has a large amount of creativity to it and there are numerous judgment calls to be made. We sometimes call these design decisions or architecture trade-offs. Unfortunately, many who are not software developers do not understand that there are nuances and subtleties and even large amounts of creativity involved in software development. Without lack of these subtle shades, it's not surprising that many of these people without development experience can only think in extremes (technique "A" is good and must be be used by everyone all of the time or technique "A" is always wrong and should be absolutely avoided no matter what). New developers often exhibit this trait as well, but experience usually teaches them to be more willing to judge approaches and techniques against particular contexts and reduce the amount of generalization and assumptions.

Developers Aren't So Different from Others, But Then They Are

The Mythical Man-Month is one of the most often-quoted books in the areas of software development and software development management. One of its great quotes is made early in the work (first sentence of Preface to the First Edition): "In many ways, managing a large computer programming project is like managing any other large undertaking—in more ways than most programmers believe. But in many other ways it is different—in more ways than most professional managers expect." One of the key explanations of the impedance mismatch between developers and non-developer managers seems to lie in this profound statement. Developers, as a group, probably should be more willing to buy into certain proven "traditional" management approaches, but managers need to avoid falling into the trap of thinking that the tactics outlined in the latest business management book will be sufficient for managing software developers.

Opinions on What Values Most

Software developers are people too. As such, they do exhibit the same behaviors as other people. However, there are gross stereotypes of software developers that are not completely without some basis because of the high frequency of those stereotyped traits among software developers. There is great diversity in the software development community in terms of political opinions, interests, and so forth, but the idea of what is most important (quality design and code, work to be proud of, etc.) are fairly common across the industry. On the other hand, software developers (similarly to engineers in various engineering disciplines) seem to overly trivialize the need to respect the bottom line. They often cannot understand when an arguably adequate but not "best" or "perfect" solution is chosen over a better technical solution for non-technical reasons.

Conclusion

We in the software development community tend to deal with mismatches all the time. We often spend significant energy and time "gluing" things together that weren't necessarily designed to go together. Despite all of this technical experience we have making incongruent pieces work together, we still seem to have difficulty resolving perhaps the most difficult and most important mismatch of all: the mismatch between software developers and people who are not software developers. Although there are some positives that come from this (such as checks-and-balances on "science fair projects"), there is significant dysfunction, angst, resentment, and demoralization caused by this impedance mismatch.

Unit Testing is a Means to an End

Most professional software developers these days understand the importance and value of writing and using unit tests. A nice summary of some of the oft-touted and oft-realized benefits of unit testing can be found in the StackOverflow.com thread Is Unit Testing worth the effort? [my only very minor criticism is the mixing of more specialized Test-Driven Development (TDD) with the more general unit test concept]. As with most good things, however, even unit testing enthusiasm can go too far. The benefits of unit testing can lead to overly enthusiastic unit testing developers forgetting that unit tests are not the end themselves, but rather are a means to the real end.

The "end" that most software developers are striving for is delivery of software solutions that make their users' lives easier and more productive. Unit tests can be extremely valuable in obtaining this end and certainly add to software quality, but the overly zealous unit tester must beware of allowing the unit tests themselves to displace this end goal. It's all too easy to allow oneself to get so bound up in writing exhaustive and "perfect" unit tests that one puts the true end goal at risk. In the remainder of this post, I look at ways in which developers can allow unit testing to move from helping achieve the desired end to unintentionally displacing the real end and putting it at risk.

Overreaching Unit Testing

Steven Sanderson has written "the benefit of unit testing is correlated with the non-obviousness of the code under test." I largely agree with this sentiment as a general guideline. I see little value in unit testing trivial "get" and "set" methods. Some methods are more readily evaluated via code review than via unit test.

The concept of code coverage can be a useful one as long as it's not taken too far. Code coverage appears to provide high return for the effort for a while, but there comes a point of diminishing returns when gaining additional code coverage comes at much greater cost and may not be worth that cost. It's also important to recognize that even the often highly expensive 100% code coverage typically means only all lines of code were executed and does not check all possible paths through the code.

All Code's Unit Testability is Not Equal

The post Selective Unit Testing – Costs and Benefits clearly articulates well the differences in difficulty (cost) and advantages (benefits) of unit testing of different types of code. In cases where the advantages/benefits of a unit test are high and the cost/effort is low, the value of unit testing is obvious. On the opposite extreme, there are types of code that receive little benefit from unit testing.

There Are Other Effective Types of Testing

I have seen multiple disparate groups of developers build and unit test their respective code bases flawlessly and then suffer through the pain of trying to integrate their thoroughly unit tested code with the other groups' thoroughly unit tested code. This happens when the involved groups have written comprehensive unit tests based on their own assumptions and without regard for functional and integration tests. A certain minimum number of unit tests are always necessary, but there may be cases where less important unit tests should not displace better or more comprehensive integration tests. When looking at code coverage, I prefer to look at code coverage from all types of tests rather than simply code coverage provided via unit tests.

In his insightful column Breaking Away From The Unit Test Group Think, Cedric Beust (created TestNG and wrote Next Generation Java Testing) wrote:

I also question all the attention that unit tests are receiving at the expense of the other kinds of tests (functional, integration, etc.). The truth is that functional tests serve your users, while unit tests serve you — the developer. A unit test is just a convenience that allows you to track down bugs faster. At the end of the day, the reason you write tests is to make sure that your users will be able to be productive with your application, not to make sure that you can debug faster.

I also like how Igal Tabachnik puts it in the post Where unit testing fails: "The road to successful unit testing begins with understanding what unit testing is, but most importantly – what it isn’t."

Unit Testing is Not the Sole Means to the End

Not only are there other valuable types of testing, there are also other valuable software development tactics and methodologies for producing high-quality software the meets or exceeds customer expectations. Unit testing is a valuable part of this overall approach, but should not diminish or overshadow other approaches such as design and code inspections, appropriate collaboration, code analyzers, and so forth.

Sacrificing Other -ilities for Testability

As valuable as I believe unit testing is, the thing I probably find most frustrating about unit testing in Java is having to compromise a desired language design feature in production code for the sake of unit testing. To be sure, there are many cases where unit testing encourages better practices in the production code. For example, unit testing encourages smaller methods, a feature that is generally considered a strength in code maintainability and readability. However, there are times when I want to make my class final or a method final or private and this can be orthogonal to unit testability.

It galls me to have to give up long-term design considerations and benefits to make testing possible. I want the software I deliver to be of high quality and enjoy readability and maintainability. It is difficult to have to give some of this up in some cases in the name of testability. Fortunately, unit testing often forces better design. But in the cases when I must choose between elegant design and production code with hacked test code to test that elegant design or hacked design and production code to accommodate elegant test code, remembering that unit testing is not the end itself provides the appropriate frame of reference for making that call.

The good news is that modern unit testing frameworks are steadily reducing the types of desirable traits in production code that must be compromised to support unit testing. Unit test frameworks such as PowerMock use bytecode manipulation to overcome most of these issues.

Group Think

Whether we call it the Lemming Effect or peer pressure or group think, there's no question that we in the software development community tend to chase fads and shiny things. Unit testing has been part of software development for many years, but the increasing emphasis on it over the last decade has benefited software development. Unit testing has a long history in software development and has long since proven itself to not be a fad. However, I sometimes feel that some developers (particularly those who don't realize how long unit testing has been around) think it's something new that the rest of us don't understand. In their zeal to promote it as a "new thing," they actually make the act of unit testing more important than the goal of unit testing.

It is often the case in software development that evangelists and defenders of a particular product, language, framework, or technology cannot allow for any hint of a weakness or disadvantage to be discussed in relation to their favorite item. Any suggestion that their preferred product might not be the best thing since sliced bread is met with derision and scoffing. This ridiculous and unrealistic stance reduces constructive discourse about the advantages, disadvantages, opportunities, risks, and costs associated with a given approach. In the case of unit testing, this might be compounded by the fact that this practice was met with some skepticism by a large number of developers for numerous years and strong evangelism to change that has been largely successful but doesn't know now how to contain itself.

Conclusion

This post has assumed constrained resources and schedules. For those who have the luxury of not facing constrained resources and short timetables, there may be sufficient time to write and maintain all of the tests for all types of code no matter how trivial and still deliver a final product in time. However, many of us are in circumstances where costs and benefits of different aspects of software development must be evaluated. In such cases, it is important to keep focus on the true long-term goal and use effective unit testing to achieve this goal while not allowing unit testing itself to become the end goal. As with most things in software development, the level and type of unit testing should based on experienced judgment of the value gained versus the cost expended. Unit testing is a means to an end; it is not the end itself.

Referenced and Other Related Resources

• Breaking Away From The Unit Test Group Think (30 August 2011)
• Selective Unit Testing – Costs and Benefits (4 November 2009)
• Is Unit Testing worth the effort? (January 2009)
• From Podcast 38 (31 January 2009)
• You Might Be Looking At Unit Testing All Wrong (11 February 2009)
• How to Quantify the Value of Unit Testing (7 September 2011)
• Unit Testing Myths and Practices (5 January 2012)
• The evil unit test. (27 January 2012)
• Where unit testing fails (24 June 2011)
• Unit tests lie: that’s why I love them (21 October 2011)
• Your Unit Tests Lie to You (17 February 2009)
• Ten Reasons to Write Unit Tests (31 May 2010)

Software Development Posts of Interest - March 2012

This post references some of the recent blog posts and articles that have interested me. Topics include Java-specific topics such as Java EE, JavaFX, Scala, and Gradle as well as more general software development topics such as software patents and open source.

Why Software Patents are Evil

Simon Phipps summarizes in Why software patents are evil why patents in software may not make sense:

Patents may work in other industries, where the cost of innovation is so high that a temporary, state-sanctioned monopoly provides just enough time to gain a return on the investment. But that investment-return ratio has a completely different value for software. It turns out that software patents have little bearing on encouraging innovation. ... Software patents are ... bad news for most innovators in the software industry.

Phipps also looks at the relationship between software patents and open source software. He writes, "The problem is that open source software is defenseless against the anticompetitive abuse of patents."

Java EE 6 Versus Spring Framework

In the post Why is Java EE 6 better than Spring? Arun Gupta discusses why he believes developers should use Java EE 6 rather than the Spring Framework. Gupta begins the post by referencing several similar blog posts including Java EE wins over Spring and Why I will use Java EE (JEE, and not J2EE) instead of Spring in new Enterprise Java Projects in 2012.

Some of the feedback comments on this post are interesting because they demonstrate the differences of opinions between Java EE evangelists and Spring Framework evangelists (with comments from employees of both Oracle and SpringSource/VMWare among them). It is interesting to see the role reversal in this situation. Evangelists of the Spring Framework (even before it was so named) helped convince the Java enterprise development community of the problems with early J2EE, but now it seems the tables have turned and similar evangelism is advertising the "legacy" nature of Spring Framework as compared to modern Java EE.

Java EE 6 vs Spring - let's get ready to rumble provides another look at this post.

Oracle's Long-Term Intentions for Java

Paul Krill's Oracle lays out long-range Java intentions summarizes the "Oracle slide presentation entitled 'To Java SE 8 and Beyond!' posted on the QCon conference website." Based on Krill's summary, this presentation sounds very similar to the Oracle OpenWorld 2011 presentation From Java SE, 2012, to Java 12: Java SE Roadmap.

Reducing Memory Usage and Garbage Collections with -XX:+UseCompressedOops

Stuart Leneghan's post Reducing Java Memory Usage and Garbage Collections with the UseCompressedOops VM Option looks at the author's observation of the -XX:+UseCompressedOops HotSpot-specific JVM option "[reducing] the memory usage of the application by 14% and the number of garbage collections by 24%."

More on Java Tuning

Speaking of Java performance and memory tuning, Rupesh Ramachandran's post Java Tuning in a Nutshell - Part 1 provides a "JVM tuning cheat sheet" and categorizes JVM options into four categories: garbage collection, heap tuning, logging, and other performance.

The IBM DeveloperWorks article From Java code to Java heap is fairly comprehensive, providing background details on JVM memory handling and a focus on the impact of different Java collections on memory. This article also references the HotSpot option -XX:+UseCompressedOops as well as the similar IBM JVM option -Xcompressedrefs.

Understanding Garbage Collection is another recently-posted resource. This post is "the first of a series of 'Become a Java GC Expert' articles" and its focus is on introducing garbage collection in Java. The same site also hosts the blog post How to Analyze Java Thread Dumps. Figure Out Why Java is Eating CPU provides an interesting tip.

Scala

There continues to be a profusion of Scala posts. Recent posts include How Scala Can Improve Your Life, Is Scala making the right steps forward?, Scala creator Martin Odersky fends off critics of Scala's roadmap, Free online books for learning Scala, and Scala: Sink or Swim? Part 1. I have also seen new references to Twitter's Effective Scala.

Unit Testing

Neil Buesing's post How to Mock Final Classes in Unit Tests examines the problem that "both Mockito and EasyMock cannot mock classes (or methods) that are final." The feedback comments are also informative and discuss other available solutions to this issue: PowerMock), Groovy-based gMock, and JMockit.

Improved Java Stack Trace Presentation

Tomasz Nurkiewicz has posted two blog posts on how to improve Java stack trace experience using the Logback Project. Filtering irrelevant stack trace lines in logs demonstrates his "proof-of-concept" for filtering out selected stack trace frames using Logback and references the StackOverflow thread Cleaning noise out of Java stack traces. An older post, Logging exceptions root cause first, discusses a feature he contributed to Logback for displaying exceptions with root cause first rather than last.

A Peek at NetBeans 7.2

Geertjan Wielenga's NetBeans Java Hints: Quick & Dirty Guide provides a peek at a capability coming in NetBeans 7.2 for creating NetBeans hints.

Gradle

Last milestone for Gradle as it prepares for first major version cites the Gradle roadmap and states that the current version of Gradle ("1.0-milestone-9, released on 13th March 2012") "will be the final one" before Gradle goes into release candidate.

GroovyFX and JavaFX

Gradle is not the only product in the Groovy ecosystem with recent version advancement news. Dean Iverson has announced the GroovyFX First Official Release. He also shows how to use Grape to "grab" GroovyFX similar to the approach shown in my post Easy Groovy Logger Injection and Log Guarding.

Other interesting recent posts related to JavaFX include Example CSS Stylying in JavaFX, New in JavaFX 2.1: ComboBox, and Packaging JavaFX Applications as Native Installers.

Groovy and DevOps

In the post Groovy, A Reasonable JVM Language for DevOps, Geoffrey Papilion writes that Groovy provides the "JVM glue" he sought for "a simple JVM language that allows me to use any native object." After demonstrating use of Groovy for a "quick script to get data from JMX into ganglia fromSsolr," he concludes

So, if you're working in a Java with a bunch of Java apps, think about giving Groovy a chance for writing some of your monitoring tests, and metric collectors. It is a simpler language than Java to put together those little applications that can tell you how your system is performing, and well within the reach of your average DevOps engineer.

DNS for Software Developers

Doug Rathbone's post DevOps DNS for Developers – Now There’s No Excuse Not To Know is intended to help software developers become more familiar with the basics of DNS. This does seem like the sort of article one would except to be associated with the DevOps movement.

The Big Three JVM Languages

The Big Three – Scala, Clojure and Groovy is a blog post with observations about Groovy, Scala, and Clojure seeming to be the most popular JVM languages among Java developers based on two polls (Which alternate JVM language do you prefer? and Which JVM Language Is On Top?). Charles Oliver Nutter has added a feedback comment regarding JRuby being a more popular JVM language when you consider Ruby developers.

Java 7 WatchService

The post What’s New in Java 7: WatchService describes java.nio.file.WatchService and calls the related functionality "one of the more interesting ... new features in Java 7." This is a fairly concise post that quickly introduces the functionality and includes sample code.

Opinions on Rails, Hibernate, Google, JSON's License Agreement, and the Spanish Theory of Management

I started this post with reference to an opinion-oriented post on open source and patents. It seems symmetrically pleasing to close this post with references to other opinion-oriented pieces. Tyler Menezes discusses technical and cultural reasons he won't use Ruby on Rails in the simply titled post I will not learn Rails. James Whittaker provides a articulate and insightful post Why I left Google.

Rob Gordon is "not impressed" with Hibernate 4.1 ease of use. The Dodgy Coder blog ("Never trust a programmer in a suit") includes a post on the "Spanish Theory" of project management.

Brian Fox points out that JSON's license agreement states "The Software shall be used for Good, not Evil." Fox further points out that "compliance is impossible" and that "this isn't even open source." He asserts that "this additional clause adds an unnecessary complication" and I tend to agree. The folks in suits are not comfortable with objective statements in the license agreements.

Conclusion

I have summarized and linked to Java-specific and general software development posts of interest in this blog post. The software development industry continues to be ever-changing and full of news.