Must-Read Software Development Resources for 2009

This post is really two posts in one. The first (and lengthier) portion focuses on online blog posts and articles that I consider "must-read" for software developers. The second, shorter section provides a quick overview of the articles contained in the most recent edition (Winter 2009) of the RMOUG newsletter.



Must-Read Software Development Articles of 2009

With so many books, printed articles, online articles, online blogs, and other sources of information on software development, there is no way for any individual to keep up on all of the best documentation available. In this section, I look briefly at some of my favorite online resources from 2009. If you have not seen these articles and blog posts, I highly recommend them. In my opinion, each of these provides value worth the time spent reading them. As a matter of modesty, I'm intentionally leaving off my own articles and blog posts for this list (I shamelessly plugged my own ten most popular blog posts of 2009 [in terms of page hits] in a previous blog post).

Most of these blog posts and articles will never enjoy the long-term fame and reverence that articles like No Silver Bullet - Essence and Accident in Software Engineering (PDF) and What Every Computer Scientist Should Know About Floating-Point Arithmetic receive. However, these are worth reading in 2009 and 2010. Finally, I don't agree with everything contained in everyone of these articles, but I think they are all thought-provoking. Here they are in no particular order.


2009 CWE/SANS Top 25 Most Dangerous Programming Errors
http://cwe.mitre.org/top25/

Knowledge and understanding of current version of this list of the top 25 most dangerous programming errors can potentially help a developer not make them those errors in the first place, saving their clients and organizations significantly in terms of money, effort, and reputation.


Software Design Review
http://philip.greenspun.com/software/design-review

This article is blunt and to the point, exactly the thing its authors argue reviewers need to be (after first being technically capable). The article includes sentences such as this, "The average programmer does terrible work, producing bug-ridden code with non-existent documentation." The conclusion starts with this gem:

Programmers will not keep themselves honest. If left to their own devices, they will skimp on anything that is necessary but not fun. This includes planning, documentation, and testing. Only a review by an unbiased external reviewer can give a non-technical management the ammunition it needs to get programmers to behave like engineers.

As with any generalization or stereotype, there are exceptions to this, of course. However, I do think its a generally true assertion. I will also add that this varies by organizational culture. I have been fortunate to work in several organizations and on several projects where there is a pride in engineering that overcomes the seemingly natural programmer inclinations.


Simplicity is Complicated
http://avdi.org/devblog/2009/10/29/simplicity-is-complicated/

This is a blog post that I wish I had written. It articulates well concepts I've touched on without ever fully covering like they are covered in this relatively brief post. The author discusses how we developers often use "simplicity" as an excuse for development misbehavior or well-intentioned but bad decisions. I think the author's point regarding simplicity is insightful. "Simplicity" or "simple" can be used as a euphemism for other not-so-good things in a way similar to how the idea of flexibility at all costs is often misused and abused.


What Should We Teach New Software Developers? Why?
http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext

This opinion piece published as part of the Communications of the ACM is relatively lengthy, but is compelling reading for anyone interested in how academia and the business world need to work together better to properly prepare college students for the "real world." Although it is part of the January 2010 edition, it actually came out in December 2009 and so qualifies for this list. Although this piece stands on its own, the credibility of the author's arguments are bolstered heavily by the fact that the author, Bjarne Stroustrup, is well-known for his professional career (not the least of which is the invention of C++), but now is a faculty member at Texas A&M. It is probably difficult to find a more qualified individual to talk about how to better meld academia with professional needs and expectations.


Ten Things I Hate About Software Development
http://blog.jtimothyking.com/2009/07/21/10-things-i-hate-about-software-development

This post is interesting because it provides a perspective on negative things I think most of us have felt at least at one time or another during a software development career. We may not have felt all ten of them or may have never experienced all then of them at the same time, but chances are, especially given a long enough career, that we all see manifestations of each of these at least once. In some cases, we may see them multiple times.

There are many reasons I like this post. First, although I have witnessed most of these at one time or another, I usually only see one or two at the same time and seeing them all together at once makes me realize how fortunate I have been for the most part. Second, the author (J. Timothy King) refers to these things as "diseases" and he lists "antivirus" approaches for preventing or reducing each of them. Finally, I like the post because it has the raw emotional edge associated with posts written with deep feeling and brutal honesty. Much of what we write and read in our business is cold and emotionless or is the other extreme: all emotion with little or no factual basis or value. This post mixes obvious emotion with some practical advice.


Self-Motivation for Developers
http://tiagofernandez.blogspot.com/2009/01/self-motivation-for-developers.html

The appeal of this blog post is that it lists and very briefly discusses ten different things a software developer can do to generate and maintain motivation. When I read this, I immediately recognized how many of these had benefited me in the past. These are some good steps to take to deal with the frustrations of software development highlighted in the previously mentioned post.


Working with Your Angry Coder
http://blog.curiouscoding.com/?p=6

Self-acknowledged "angry coder" Michael O'Hearn started 2009 with this post detailing how to work with and stand being around an "angry coder" (which he describes in the opening paragraph that includes the sentence "They read about the newest trend and want to go back and fix all of the work that was done the wrong way."). The author uses his experience being the angry coder and working with the angry coder to outline steps developers can follow to better deal with these angry coders. This is excellent for people who have to deal with angry coders, for people who need to recognize their own angry coder within them, and for those of us who experience a little of both.


The Zealots of Agile
http://www.sdtimes.com/link/33300

This column is representative of the types of opinion pieces I like to read; pieces that challenge extremism in development. The author makes it clear that he is attacking rabid agile evangelism rather than Agile itself. I feel much the same way. Although there are numerous desirable facets of Agile, the extreme admit-no-weakness attitude of some agile proponents actually hurts its cause rather than helping it. I have seen several self-recognized agile experts state how easy it is to tailor agile to accommodate any project of any size with any group of developers. My experience is that this is simply not true, but the most fanatical agile evangelists refuse to admit that agile might be better suited for certain situations and not be the best fit for every situation. This illogical and highly emotional evangelism is yet another manifestation in software development of Maslow's Golden Hammer. More generally, any type of science (and I'll include computer science here loosely as a "science") benefits from healthy debate and consideration of alternative theories and ideas; we all benefit in software development when we avoid the Lemming Effect (see also Software Lemmingineering) and are open to new and potentially better ideas.


How To Become An Expert. Top Seven Qualities
http://softwarecreation.org/2009/how-to-become-an-expert-top-7-qualities/

The graphic at the top of this post is particularly interesting. A colleague commented that this seems very similar to a graphic from one his all-time favorite software development presentations (Dave Thomas's Herding Race Horses and Racing Sheep).


The Duct Tape Programmer
http://www.joelonsoftware.com/items/2009/09/23.html
http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer

Joel Spolsky's The Duct Tape Programmer elicited many replies in the blogosphere, but I couple his original blog post and Bob Martin's follow-up blog post of the same name here. I believe these two should be read together. Martin agrees with most of Spolsky's original post and I agree with most of what both these seasoned professionals have to say on the matter. I think it is refreshing to see consultants agreeing that it is important to get a product to market.

Both the Spolsky post and the Martin post are useful reads in and of themselves, but the feedback comments are also interesting. Furthermore, they reference other good resources. For example, the original Spolsky post clearly states that the thoughts are provoked from reading the first chapter (Jamie Zawinski commentary) of Coders at Work. There is also a link to the article The Rise of 'Worse is Better.'


Ten Papers Every Programmer Should Read (At Least Twice)
http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-programmer-should-read-at-least-twice

This post is a cheat for my list in that it is really a blog post outlining ten more articles that Michael Feathers believes all programmers should read and most of these are many years old rather than being written in 2009. However, Feathers's post was written in 2009 and does include his insight into why each is worth reading at least twice. Furthermore, the comments from readers are excellent as well and add several more good articles (many again older than 2009) that just about every software developer should read.


Ten Pages Every Software Architect Should Read (At Least Twice)
http://dobbscodetalk.com/index.php?option=com_myblog&show=10-Papers-Every-Software-Architect-Should-Read-At-Least-Twice-.html&Itemid=29

The author of this blog post was inspired by the last one of similar name. This includes several other articles well worth reading.





RMOUG Winter 2009 Newsletter

I received my copy of the Winter 2009 edition of RMOUG SQL>Update (the RMOUG newsletter) in the mail. It features several interesting articles including Mark Molnar's "Oracle & Excel - Why Fight It?" (which appears to be the first of two parts with the second part expected in the Spring edition), Mathias Magnusson's "The Case for CASE", Dan Hotka's Index Monitoring, and Don Burleson's Function-Based Indexes.

If you are a member of the Rocky Mountain Oracle Users Group, I highly recommend this edition of the newsletter. I really like the full-color pages, especially of the screen snapshots in Molnar's article of using Excel with the Oracle database. There are also several advertisements in this edition reminding readers about RMOUG Training Days 2010 registration.

So far, I have not been able to find any of these articles available online for people who are not members of RMOUG. However, there are some similar articles available online. For example, Connecting with Oracle: Accessing Oracle via Access and Excel (2004) talks about using Microsoft ODBC to allow communication between Excel and Oracle similarly to how Molnar's article discusses use of Visual Basic and ODBC to do the same thing. The online article The Power of SQL CASE Statements covers CASE statements, the same topic covered in Magnusson's article.

Although I could not find the particular versions of the Hotka and Burleson articles in the Winter 2009 Edition of the RMOUG newsletter available online, both of these authors have made similar work available online. Hotka's presentation Tuning SQL When You Cannot Change the Code touches on index monitoring along with several other Oracle database tuning tips. Burleson has made an excerpt of the Mike Ault book 10g Grid and Real Application Clusters available as an online entry called Using Oracle Function-Based Indexes.

What Was the Most Significant Java Event in 2009?

I recently blogged on the software development events in 2009 that seem most significant to me. Although the list was certainly biased toward Java, it was not exclusive to Java. Nevertheless, my number one choice was the Oracle acquisition of Sun Microsystems, which will undoubtedly have a huge impact to the future of software development in general and Java development in particular. The current Java.net poll asks which Java/JVM event of 2009 developers think is most significant. Not surprisingly, over half of the current ~260 votes is for the Oracle acquisition of Sun.

The poll includes other Java/JVM events and news of 2009. These are options are closures in JDK 7, Java EE 6, Scala, JavaFX, Java store, and the usual "I don't know" and "Other" options.

In my blog post summarizing the most significant software development developments of 2009, I had many of these in my Top Ten. Scala was my sixth choice, JDK 7 and closures was my fifth choice, Java EE 6 was my third choice, and the Oracle acquisition of Sun was my first choice. I did not have JavaFX or Java Store in my top ten or honorable mention.

After The Acquisition, closures in JDK 7 and Java EE 6 are the distant second and third most voted for Java 2009 developments and that seems about right to me. Oracle's buying Sun seems to have both the most significant short-term effect and even greater long-term effect on Java development. By the way, had IBM purchased Sun, the magnitude of that effect would be similarly large even if the details were somewhat different.

As big as the Oracle acquisition of Sun is for the Java community and ecosystem, it obviously goes beyond the Java world. MySQL alone has been a major issue in this acquisition process. There are other Sun products that have little or nothing to do with Java. And, of course, Java is one of the most significant players in software development so even events particular to Java have ramifications for all of software development.


Tools for Three JVMs

Speaking of Oracle and Java, James Bayer's recent blog post Open the Black Box - Oracle JRockit, Sun Hotspot and IBM J9 JVM Tools provides a brief overview and comparison of tools useful for monitoring and performing diagnosis of JVM performance for the three most significant JVM providers.

Best of 2009: A Software Development-Oriented Collection

It's that time of the year when it is popular to list top articles, blog posts, and features from the previous year. This blog post collects some of these "best of" collections for 2009 that are related specifically to software development. I also include my own top ten list of the top ten posts in my blog during 2009.


Most Popular of Cogitations and Speculations

The ten most popular posts in my blog were as follows (in order from tenth most popular listed first to most popular listed last):

12. Must-Have Flex Development Tools Sans FlexBuilder (14 February 2009)
11. Bare Bones BlazeDS Object Remoting (1 January 2009)
10. Flex: Proxied HTTPService and REST (9 February 2009)
9. Day-to-day Java Development Tools and Techniques (17 February 2009)
8. RESTful Database Access with sqlREST (1 June 2009)
7. Easy Java-based REST Testing Tools (3 January 2009)
6. Bare Bones BlazeDS HTTPService Example (9 May 2008)
5. Java Collections Class (16 March 2009)
4. Using RESTClient with Java's HttpServlet (21 January 2009)
3. Simple Remote JMX with GlassFish (19 May 2008)
2. Useful Online Java Developer Resources (31 December 2008)
1. Effective Java NullPointerException Handling (25 April 2009)

The "Top Ten" actually lists 12 blog posts because the third and sixth most popular posts in 2009 were actually written in 2008. A third post, the second most popular post, was technically written in 2008, but was written on the last day of that year so I did not feel a need to list a third post actually written in 2009.

The top ten/twelve of my most popular blog posts indicate that the most popular posts on my blog in 2009 were those that are tailored to a specific technology and are highly detailed. For example, these top posts cover facets of Java, Flex, REST, and so forth and often cover a particular narrow portion of these technologies with relatively significant detail.

I enjoy writing more general posts, but it is obvious that these are not among my most-read, so I'll likely shift some focus in 2010 back to emphasize more writing highly detailed, narrowly focused blog posts.


Programming and Development: Best of 2009

The Justin James-hosted blog Programming and Development features a list of the top five posts of 2009 for that blog. The top five are Ten Tips to Go From a Beginner to an Intermediate Developer, Strategies for Learning Programming Languages, Frustrated by a Co-Worker's Use of Old-School Programaming Techniques, Why Did You Try Programming?, and The Current and Future State of C++.


Top Ten Technology Stories of 2009

Not surprisingly, the still-in-the-works Oracle acquisition of Sun is the "big story of the year" cited in this list of top technology stories for 2009. Other stories include the launch of Windows 7, Google Chrome, and Droid.


Oracle Technology Network/Oracle Magazine 2009 Most Popular Articles

Oracle Technology Network (OTN) Editor-in-Chief Justin Kestelyn posted the top ten articles and downloads from OTN and Oracle Magazine in the post The Most Popular Articles and Downloads of 2009. Many of these articles are of interest primarily to Oracle database administrators, but there are some articles on the list of greater relevance to software developers. These include High-Performance Oracle JDBC Programming, Taking an Oracle ADF Application from Design to Reality, and Oracle ADF Development Essentials.


Best of developerWorks Web Development Zone in 2009

A Few of My Favorite Things: A Look Back at the Web Development Zone in 2009 lists articles that developerWorks Content Acquisition Editor Chris Warden feels must not be missed from the 2009 articles on web development. This includes articles on Accessibility in Web 2.0 Technology and Scalable Vector Graphics and Bitmap Rendering Using Flex.


The developerWorks Java Articles You Wish You'd Read Earlier

This is a collection of articles that developerWorks Java Zone Editor Jenni Aloi put together based on criteria outlined in the comments section. They are Java-centric and cover topics such as Groovier Spring, Easier Testing with EasyMock, Google App Engine for Java, and JPA 2.0 Criteria API.


Open Source in 2009

2009 Open Source Top Ten lists Chris Wanstrath's "favorite [open source] releases of 2009" and include products such as Unicorn (Unix-based HTTP server for Ruby/Rack) and yajl-ruby. Ten Greatest Open Source Software of 2009 focuses more on open source end products such as SVG-capable Inkscape and GIMP (GNU Image Manipulation Program).


Other "Best of" and "Top" Lists

The 15 Best Articles for Designers in 2009

120 Tips, Tricks, and Tuts from 2009 Worth Your Time

The Top Ten Tech 'Fails' of 2009

Top Ten Software Development Predictions for 2009

Rational Top Ten Articles from 2009

Top 15 developerWorks WebSphere Articles of 2009

The Ten Best of the Newest Content in the XML Zone


More to Come

With 3 week days still left in 2009, it is likely we'll see more "Best of" and "Top Ten" lists this coming week. I plan to add them to this post as I run across them.


Conclusion

There were some common themes in the collection of top stories, blogs, and articles. Oracle's tentative acquisition of Sun, Java, REST, and Flex were among those subjects represented on more than one of these "best of" and "top" lists. See my last blog post, Significant Software Development Developments of 2009, for coverage of some of these concepts from the perspective of major announcements and developments in the world of software development.

Significant Software Development Developments of 2009

I have blogged previously regarding the events that affected me most significantly in the world of software development in 2007 and 2008. In this post, I do the same for 2009 with the usual caveats: there is no way to truly measure what is most significant and even if there was, the totals would be different for different people. A final caveat is that these things seem important now, but the real question is which of them will still seem significant five years from now and beyond.

In 2009, several of the most significant developers had obvious ties to current economic conditions.


Dustin's Top Ten Software Development Developments of 2009


10. Mergers and Acquisitions

Mergers and acquisitions occur each year, but 2009 seemed to have more than normal and featured one of the biggest acquisitions in the relatively short history of software development. In fact, the biggest acquisition is so big, that I'll reserve its own item to cover it. Not counting The Big One, other significant acquisitions in 2009 included SpringSource acquiring Cloud Foundry and then SpringSource itself being acquired by VMware and Terracotta acquiring ehcache and Quartz. Other examples include Oracle's acquisition of Virtual Iron and GoldenGate, Rackable Systems's acquiring of SGI, Microsoft's acquiring of Interactive Supercomputing, and Google's acquisitions of companies such as reCAPTCHA and Teracent.


9. The Changing Landscape of Software Development Conferences

2009 appears to mark a significant shift in the types of conferences that we will attend in the near future. Well-known and long-established conferences such as Colorado Software Summit and SDWest and SD Best Practices terminated their long-running tradition in 2009. There is speculation that 2009 JavaOne may have been the last (or second-to-last). Even if we have not seen our final JavaOne, there is now at least "controversy" regarding JavaOne's place in relation to DEVOXX.

Another interesting observation regarding software development conferences in 2009 is Java.net editor Kevin Farnham's observation that "Twitter coverage of conferences seems to be overtaking blogging, at least for as-it-happens coverage."


8. Java IDE Wars: IntelliJ Community Edition

When someone brings up the subject of Java IDEs, there are four that come to my mind. In recent years, Eclipse and NetBeans have dominated discussion of Java IDEs due to their open source and no cost nature. Oracle's JDeveloper has been dominant in shops that make heavy use of Oracle products. Although not open source, JDeveloper has been freely available for several years (essentially since 2005 JavaOne). IntelliJ IDEA has been the only one of these four dominant Java IDEs that has not been available without charge. That changed in 2009.

IntelliJ IDE now comes in a freely available, open source Community Edition and in the more traditional Ultimate Edition. I have blogged previously on the IntelliJ IDEA Community Edition and what it might mean.

Not only has the availability of an open source community edition of IntelliJ IDEA potentially changed the Java IDE landscape, but future events are likely to do so as well. Oracle's acquisition of Sun makes things interesting because Oracle already owns the proprietary JDeveloper, contributes significantly to Eclipse, and will acquire Sun's current rights to NetBeans with the Sun acquisition. In other words, Oracle will most likely be associated with three of the four major Java IDEs by early 2010.

It may seem like a minor detail, but I have some concern that the movie in the Twilight Saga called Eclipse will bump the Eclipse Java IDE right off the Google searches. :)


7. Bing Search Engine

The IDE is not the only useful tool for a developer. It can be difficult to remember what it was like to develop and debug software without extensive online resources readily accessed via powerful search engines. I remember fondly the days of Infoseek, but as good as that search engine was, it could not compete with the power of the Yahoo! search engine that would replace it. The Google search engine has been my favorite for years and its extensive use has led to the coining of new words. However, the release of Microsoft's Bing search engine is, at the very least, likely to improve our ability to search rapidly for data due to the competitive environment in the search engine space. I have found Bing to be useful as my second search engine that I use when Google search results are not providing what I want. The search engine aggregation site Dogpile Web Search conveniently brings the best of Google, Yahoo!, Bing, and Ask.com together in one site.


6. Scala

In last year's countdown of significant software development happenings, Scala made the "Honorable Mention" section. James Iry (a contributor to Scala Blog) made some compelling arguments for why Scala itself and Scala as representative of a larger movement had earned more than Honorable Mention. This year, it did make my top ten because of its undeniable growing popularity and the obvious impacts it is having on other JVM languages and on concepts of how to develop software (especially JVM-based concurrent software). It seems to currently have more momentum than other languages such as Erlang and Clojure.

As evidence of the growing popularity of Scala, witness the several books on Scala. Bill Venners has explained some of the features that have made Scala desirable in Bill Venners on the Rise of Scala and Getting Dynamic Productivity in a Static Language.


5. Java SE 7 News ... Again

No matter what it is called (Java 7, Java SE 7, JDK 7), the next major release of Java continues to make news despite not being delivered in 2009. It now appears that JDK 7 will be released later in 2010, but in 2009 we started to get a much clearer picture of what will be in this next version of the Java programming language. Closures, which were originally thought to be out, now sound like they may be back in JDK 7. New Java packaging and modularity concepts have led to the now famous (at least in Java circles) quotation, "The classpath is dead." Project Coin has some nifty features and syntactic sugar that appears destined for JDK 7. See Alex Miller's excellent Java 7 page for details on other aspects of Java 7.


4. Groovy

In my countdown of significant software development developments of 2008, I listed dynamic JVM languages in the honorable mention section. This year, Groovy earned its own mention and earned its way into the top ten proper.

The year 2009 saw new releases of Groovy with the final release of 1.6 (18 February 2009), with versions 1.5.8 and 1.6.1 (7 April 2009), and Groovy 1.7 (22 December 2009). There were some very nice new features added to Groovy in the 1.6.x and 1.7 releases.

The announcement of the 1.7 release refers to Groovy as "the most popular and successful dynamic language for the JVM!" This certainly seems to be the case. For evidence to back up this claim, witness the relatively high number of books on Groovy (and Grails) now available. Other evidence of the popularity of Groovy is provided by the existence of a DZone area dedicated to Groovy (Groovy Zone) and the unusually high number of "up" votes for the DZone article highlighting the Groovy 1.7 release (~230 at time of this writing compared to ~20 for announcement of release of Java EE 6).

I think that one of Groovy's greatest appeals is that it can be so easily learned and applied by experienced Java developers. Just as important is the ability to use it for building scripts in the development process, using Groovy-based build tools, and even being able to use Groovy to write full applications. The ability to choose at what level to expose Groovy (just in the building or in the actual production software) makes it appealing to a wider audience. An organization that is not comfortable using Groovy in its production applications, for example, could still find great benefit in using Groovy to build its production applications. In fact, the focus of my RMOUG Training Days 2010 presentation (Applied Groovy: Scripting for Java Development) is on using Groovy in this way.


3. Java EE 6

The December release of Java EE 6 is a significant development in the enterprise space. This release offers many attractive new features such as web profiles, Managed Bean 1.0 (JSR 299/Web Beans and JSR 330; not to be confused with MBeans or MXBeans of JMX fame), standardized database resource definitions, EJB 3.1 (JSR 318), Servlet 3.0 (JSR 315), JPA 2.0 (JSR 317), and inclusion of JAX-RS 1.1 (JSR 311),

A recent series of articles introducing new features of Java EE 6 complement the Java EE 6 Tutorial. They are "Introducing the Java EE 6 Platform" Part 1, Part 2, and Part 3.


2. Programming Environments for Mobile Devices

The year 2009 saw some major announcements and releases related to software development for mobile devices. In particular, I found it interesting that Adobe plans to support developing for the iPhone using Flash (using ActionScript with Flash Professional CS5).

The second major development in this space was the release of Android 2.0 SDK (October) and 2.0.1 SDK (December) as well as the release of the Motorola/Verizon Droid, which supports development of applications using the Android SDK (and the Dalvik virtual machine). If this wasn't enough, Google also announced the release of the Android Native Development Kit (NDK) for Android developers to use C/C++ in performance-critical portions of their applications.


1. Oracle Buying Sun

Almost immediately after we all heard that IBM had dropped out of negotiations to purchase Sun Microsystems, we heard that Oracle intended to purchase Sun. Although this was originally announced in April 2009, the deal is still not finalized due to (at least ostensibly) European Union concerns regarding MySQL. However, recent word is that a deal has been struck between Oracle and the EU and the deal is expected to finally go through early in 2010.

This acquisition is huge. There is much speculation (including in my own blog) regarding the future of various Java-related products, of various open source products of which Sun is the primary sponsor, and of Java itself under Oracle stewardship. Despite this speculation, most of us have no concrete idea of what will happen and are waiting to find out. Even developers who do not use Sun products, Oracle products, or Java-related products are likely to be at least indirectly affected by this acquisition because it will almost certainly affect the entire software development competitive landscape.


Honorable Mention

The following are developments that did not make my top ten, but are significant or potentially significant.


Go

It is difficult not to tire of all the new programming languages that promise to be the next big thing and to do everything for the developer short of slicing bread. Still, the attention showed on Google's Go programming language (not to be confused with the Go! language) warrant keeping an eye on this language. Go's Language Design FAQ describes Go as "an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language."

Go is a "systems programming language" which runs on Linux or MacOS and seems to be aimed primary at C and C++ developers as evidenced in both the Go Tutorial and the Go for C++ Programmers page.

The software development corner of the blogosphere was filled with blog posts regarding the Go announcement in late 2009. Some of the blogs and reviews of the language (only a small subset) that provide insight into the language itself include Twelve Things to Know About Google's Go Programming Language, Is Google's Go Language Worth Learning and Teaching?, Google's New Language: Go, and Facts of Google's Go Programming Language. For a contrarian opinion regarding Go, see Google Go Not Going Anywhere.

The fact that Google's Go is still considered "experimental" (the FAQ states about Google's internal use of Go: "implementation isn't quite mature enough yet for large-scale production use") means its highest ranking I could give it is "honorable mention." That fact that it's associated with Google and individuals such as Rob Pike and Ken Thompson is what, in my mind, justified this experimental language making the list at all. Note, for example, that the noop language did not make this year's list.


Cloud Computing

When it comes to cloud computing, I remain a skeptic. Having said that, many very bright people who I truly respect have wagered significant time and resources on cloud computing initiatives, so I cannot completely dismiss it out of hand. Regardless of where its future lies, there is no question that it has been talked about a lot in 2009 and hence it made the "honorable mention" portion of this list. If it turns out to be even half as successful as some of its ardent supporters claim it will be, it is likely to make the Top Ten proper in a future year.

There are several resources for contrarian (or at least "hype countering") opinions regarding cloud computing. These include Software Development's Winners and Losers, 2009 Edition (which lists "cloud hype" as a winner and "cloud reality" as a loser), Open Source Guru Rails Against Cloud Computing 'Hype', Cloud Computing is a Trap, Warns GNU Founder Richard Stallman, and CIO Cloud Computing 101: Problems with Clouds.

For every negative article and blog post on cloud computing, there seems to be many times that number of positive articles and blog posts. A small sample of these includes Cloud Computing: Hype Versus Reality, Cloud Computing: Hype or the Next Big Thing?, Oracle Cloud Computing Center, 2009: The Year the Government Discovered Cloud Computing, and Cloud Computing Grows Up.


The Demise of Geocities

The end of the the previously freely hosted Geocities pages and sites was significant to me in 2009, perhaps at least partially due to a biased nostalgia due to having a simple home page hosted there for many years. The end of the once highly trendy and popular web page hosting site not only meant the potential loss of historically valuable information, but also served as a reminder that technologies and peoples' desires for technology change rapidly. For software developers in particular, it is a reminder that what works for us today may not sell tomorrow.


Economies of Open Source

In the blog post The Problem of the Open Source Commons: Harsh Economic Realities of Open Source Software, I wrote about the struggle for sponsors of open source software to earn enough from implementation and support of the open source product to justify the time and resources invested in that product. This has been a long-identified issue with open source software development, but 2009 has seemed to bring renewed focus on the subject.

In 2009, we learned of the impending sale of one of the major open source sponsors, Sun Microsystems, to Oracle. We also learned of the economic struggles of open source development from those who know firsthand (Clojure and JFreeChart are just two examples).

I am not the only one who has written in 2009 about the economic struggles related to open source development and use. Open source is listed as both a winner and as a loser in Software Development's Winners and Losers, 2009 Edition. In the blog post Elinor Ostrom, the commons problem and Open Source, Aldo Cortesi also looks at the problem of the commons from an open source perspective.

Sponsors of open source software continue to struggle with how to get paid for the time, effort, and resources they invest in these products. Dual licenses have been lauded as one way to do this, but the complications associated with that approach have led many product sponsors to use licenses that are less burdensome to end users (partly to gain users), but that usually leads to reduced revenues. Some sponsors are financially successful with development of open source products, but many are not. I expect the general nature of open source to continue to evolve to meet different financial incentives.

There is much to like about the economics of open source as well, as highlighted in Open Source Became Big Business in 2009. This article is very positive about the future of open source. I think that open source's future is very bright, but there are some potential pitfalls to avoid.


Google Chrome OS

The announcement of Google Chrome OS made big waves, but I would like to see more long-term effect from this before making it in the top ten.


Related Resources

The DZone article Looking Back at 2009 for Java highlights some of the same things I highlighted here, but with a Java focus. I have cited the Software Development's Winners and Losers, 2009 Edition here several times.


Conclusion

2009 was a year where the economy, mergers and acquisitions, and other "business concerns" were as big for software developers as any technological advancements. Most of these developments were highly interrelated as well. It appears that many of the trends that these developments are examples of will continue on into 2010.


Comments

Did I miss a top software development development of 2009 that deserves mention here? If so pleas comment and specify that missed developnent.

When Resistance is Futile (or Worse)

I enjoyed several days in Southern California (SoCal) the week before Christmas. It had been several years since I had last visited Disneyland, California Adventure, Sea World, Universal Studios, and San Diego Zoo and it was fun to experience some of my favorite attractions (such as Soaring' Over California, Star Tours, Penguin Encounter, Universal Studios Studio Tour) and to experience some new (to me) favorites (such as Toy Story Mania!, The Twilight Zone Tower of Terror, Revenge of the Mummy, The Simpsons Ride, and Wild Arctic Ride). As much fun as it was to visit these amusement parks and zoo, the most significant downside was the large crowds (especially at Disneyland).

Despite the well-laid plans and valiant efforts by the staff members of these various parks, things did not always go as smoothly as they could have because some park visitors did not cooperate with these plans and staff directions. I couldn't help but see many similarities in software development where the best-laid plans, standards, code conventions, and other devices designed to improve productivity, maintainability, and other desirable "ilities" are less effective because a (relatively) small number of people do not cooperate. In this post, I look at some of the reasons and motivations that explain why a small minority of developers (sometimes only one!) often derail or at least reduce the effectiveness of various software development approaches and tactics. Because software developers are simply a subset of the human population, it is not surprising that the same reasons and motivations apply to software developers as to park visitors.


Explanations for Inefficient Behavior

If a particular code convention, standard, or other common approach is available to increase the productivity and maintainability of software, why wouldn't every software developer follow these standard approaches for the betterment of the entire organization? The answer to this question is essentially the same as the answer to the question, "If the parks have set up certain strategies and traffic flow patterns for an improved experience for all visitors, why wouldn't every visitor follow these practices?"


Don't Know Better

One significant cause of delays in trying to optimize crowd flow throughout the parks was the seemingly unpredictable behavior of small children. Many small children would dart any which way they wanted without regard to any directions or common sense as to what was the most effective approach. Of course, this was entirely to be expected and not at all surprising. Many parents tried to teach their children to be more careful about what they were doing. It reminded me of more experienced developers explaining to new developers why certain seemingly mundane or useless approaches might actually be worthwhile for individual and overall benefit.

Just as most people seemed to not be too bothered by young children making these mistakes, it is typically less bothersome when an inexperienced developer does not fully realize the advantages of following certain approaches designed for overall benefit. In both cases, it is often simply a matter of education to help the young child or inexperienced developer understand the value of following the plan.


Unaware of Plan, Approach, Convention, or Standard

Some of the people who were trying to walk "against the grain" seemed to be doing so simply because they were oblivious to the fact that, especially in the large crowds on Disneyland Main Street around parade and fireworks times, there was actually a preferred flow of people that Disneyland staff was trying to communicate.

Most of these offenders were adults and I like to think that many of them would have done as instructed if they had realized there was actually a plan. I liken this group to experienced developers who would follow the standard or convention once aware of it, but may not be aware of it due to being new to the organization or project. Again, this group is relatively easily helped by simply making them aware of the standard or convention.


Doesn't Apply to Me

Although many of the people at the parks and zoo who slowed everyone else down by going against the directions and traffic plans did so because they didn't know better or didn't know there was a specific plan, there was a small number of people who seemed to know better but chose to do what they thought was in their own selfish interest despite the negative consequences others experienced because of their actions. In some cases, this was a manifestation of a person believing he or she was more important than anyone and everyone else. In some cases, the offender appeared to believe that his or her actions would not cause any problems. Of course, they almost always did because everyone else was moving in conjunction and the entire group had to slow down to accommodate that person.

I actually heard one angry visitor at Disneyland say to the Disneyland employee instructing her to walk counter-clockwise around the circle between the Castle and Main Street in Disneyland reply that she would not do that. She said, "No. I'm not doing that. Sorry." She was obviously not truly sorry and felt that taking the extra 15 to 20 steps to go that way rather than the other direction was beneath her. So, of course, she slowed everyone else down who was following the prescribed path as she tried to make her way upstream through the traffic. There's no question it took her longer to get to her target location (albeit with fewer steps) and it slowed many times that number of people down at the same time.

In software development, we often see a developer who fits in this group. He or she thinks that the general approach does not apply to him or her. Sometimes this is because he or she simply doesn't want to do it and feels like doing his or her own thing won't have any serious consequences. Other times, the individual simply believes he or she has a better way and that the general approach does not apply to him or her. Not only can such behavior reduce the level of benefits from a general approach, but it can actually lead to even more detrimental behavior as The Prima Donna Effect kicks in and other developers start doing their own thing as well.

In development, a developer occasionally truly believes he or she is saving time by doing something outside of the prescribed plan, but this is often a false illusion that ends up being as bad or worse while also slowing others down. The problem is that even if the lone developer's approach is better on a single developer basis, its full benefit is only likely to be realized at an organizational level if that better approach becomes the commonly accepted approach or at least becomes compatible with the commonly accepted approach. It doesn't help overall effectiveness if one developer's saving of an hour costs five other developers an hour each.


Specific Software Development Examples

In the parks, the plans that seemed to not be as effective when visitors were either not aware of the grand plans or chose to ignore them generally involved things such as traffic flow, queuing up for popular rides, and queuing up to purchase souvenirs. The parks typically had directions and plans to make these things more efficient, but these efficiencies were lost when people ignored them. In software development, we have a similar set of well-known approaches that can be less efficient or not efficient at all when one or a small number of developers either are not aware of them or choose to ignore them.


Code Conventions

One frequently used software development approach that fits this idea is the use of code conventions. Code conventions are designed to make it easier to read and maintain each others' code. Even if the code convention is not our favorite, it is often easier to recognize and quickly read code that is similar in nature rather than code that is drastically different depending on who wrote it.

Another advantage of code conventions is less temptation for a developer to change another developer's preferred code style to his or her own code style. If both the original developer and all future developers maintain the code convention, then only significant code changes should be tracked in the configuration management system. This is no small advantage because style changes can often overwhelm "real" changes in software and make it difficult to determine what things of significance were changed from one version of code to another. Tools such as Jalopy can be useful in helping with this effort, but code reviews and adherence to the convention by developers is probably still the most effective mechanism.


Adherence to Standards

Most implementations of most standards supply some optional non-standard features that can be tempting to use. In fact, in some cases it might even be justifiable to use the non-standard features because its benefits outweigh the risks and costs. However, if an organization or client has mandated complete standards compliance, it is not appropriate for developers to use non-standard features of a particular standard implementation simply because it is easier. It may be appropriate to use the non-standard feature because the cost of not doing so is so great, but this should be coordinated and approved if standards compliance is key desirable characteristic (which it usually is). It can seem harmless to include use of a non-standard feature, especially if it is in a seldom used portion of code and/or is associated with a product that seems to be a permanent part of the delivered software. However, even the same vendor might change or remove a non-standard feature and there are never any guarantees.


Process and Logistics

A significant portion of the software development experience is associated with everyday, routine logistical tasks and process steps that are not specific to software development. Arranging for meeting rooms is an example of one of these routine tasks not specific to software development. Most large projects have procedures in place for reserving meeting rooms or any other relatively rare resource. When some individuals choose not to use those processes, they waste others' time waiting for them to vacate the room or arguing over who gets the room. Similarly, starting and ending meeting in a timely manner is a generally accepted practice that will generally benefit the entire organization when observed.


What About Thinking Outside of the Box?

One of the MBA euphemisms I most enjoy making fun of is "thinking outside of the box." It is popular to advocate thinking outside of the box and to encouraging non-conformists. Indeed, in the correct place and time these are valuable to keep an organization fresh. However, rather than one individual bucking the standards and conventions laid out so that everyone else is slowed down, it is better to work to have the general approach adjusted to appropriately incorporate fresh concepts while still retaining the value of having everyone moving in the same direction. Only if a single developer could do all development and maintenance of a product by himself or herself for perpetuity would the going solo approach be the best for an organization.

I have definitely found many places in a standardized approach where small, individual tweaks have improved my own productivity without negatively impacting others. I try to be cognizant of these almost instinctive maneuvers and advertise them to others around me. However, I have caught myself slowing others down when I have left the agreed upon approach and that is a difficult position to defend. In fact, even at the Southern California parks, I am afraid that at least once or twice per day I was the offender trying to save myself some time, only to realize I was costing others a couple of seconds because of a well-intentioned but ultimately poor choice that was not aligned with the greater plan.


Conclusion

It seems to be human nature to think that one can do something better than others and to seek individual advantage. I believe that the majority of us won't do this at significant cost to others, but we are very likely to do this if we believe it will have negligible cost to others. Unfortunately, our estimates and assessments of the potential cost to others is often incorrect and understated. It is often true that small sacrifices on our part will lead to organizational benefits and sometimes will even surprise us with benefit to our own progress.

The accumulate negative effect of a small number of visitors intentionally or unintentionally neglecting the provided guidance for how to allow the crowd to move about park most efficiently reduces the desired collective efficiency gains. Similarly, the intentional or unintentional neglect of provided guidance in certain areas of software development reduces efficiencies associated with grand plans designed for group efficiency. In the end, the individual that does not heed to the generally accepted approaches slows down the entire group for a small benefit to himself or herself and sometimes doesn't even see any benefit for himself or herself.

The High Cost of Not Asking Questions

Organizations pay a high price when their software developers do not feel comfortable asking questions of each other and learning from each other. Developers can learn quite a bit from one another and can the free exchange of ideas and solutions can directly and indirectly improve the organization's ability to deliver quality software in a timely manner. In this post, I look at some of the advantages of fostering a culture that encourages the asking of questions as well as some tips for improving this culture.

I have noticed that many software developers go through the same experience curve that I am moving through. When we first start our careers, we feel free to ask some questions because we are the new person, but we are also afraid to ask too many because of the negative impression others might have of us. As we gain experience, many of us are less confident in asking questions because we believe that our greater experience should mean no need to ask questions and that we need to know everything. The best developers, in my experience, grow out of this phase and realize that they provide the best value when they strive to find the correct mix of self learning and asking questions. The best developers have enough confidence to know that asking questions when appropriate is not a sign of weakness.


The Cost of Not Asking Questions

There are many costs associated with not fostering a culture in which developers feel free to ask and answer each others' questions.

Relearning What is Already Known

Most developers will try to learn how to do something new or how to resolve a problem for a short period of time on their own. However, experienced developers understand that there is a period of time past which their individual effort may be much less efficient than simply asking for help. This is especially true when the problems or questions are related to an area requiring deep domain knowledge that is not readily available in public forums. If any organization has developers who have learned something "the hard way," there is often no need to have everyone else expend the same effort and time if they can learn it more quickly from those who have already learned it. In software, we sometimes are guilty of reinventing the wheel and relearning what has already been learned is really no better.

Multiplying One's Knowledge

When a really experienced developer shares his or her wisdom and lessons learned with other developers, there can be many times the productivity of just that single developer enjoyed by the project. This is especially true when a small amount of time sacrificed by the person answering the questions can help multiple people proceed on with their work.

Inferior Solution

If a developer is not comfortable asking questions of more experienced (or even differently experienced) developers, it is more likely that the developer will not come up with the optimal solution. I have seen in my career several times when a developer did something less efficiently or in a non-standard or non-maintainable way simply because he or she did not know there was a better, more efficient, more standard, and/or more maintainable way. Some of these cases have occurred because the offending developer did not want to admit lack of knowledge of what he or she was trying to do. In one example, the developer wrote his own XML parsing code because he could not get the Xerces-C XML parser working. It was a simple matter of making his XML well-formed, but he did not know this and did not ask for help and ended up wasting many hours writing a custom "XML" (mostly) parser.

Frustration and Its Ill Effects

When a developer is trying to do his or her best, but needs help and is unwilling or unable to ask for it, the feelings of frustration can be overwhelming. This can have a direct impact on that developer's confidence and ability to deliver software.

Questions Can Benefit the Answerer

The act of asking questions for greater understanding often benefits the person doing the answering as much as the person doing the asking. This is because the attempt to answer the question forces the person answering it to think about the issue more deeply, sometimes in ways he or she had never thought about it before. So, questions not only make the person asking them more knowledgeable, but can also help increased the knowledge of the person answering the questions, magnifying the benefits to the project.

Questions Can Expose Holes and Gaps

Most of us have heard the expression "thinking outside of the box." Sometimes it is easier to do this when someone who is not already too familiar with that box is asking probing questions that force us to think about something from a different perspective. More than once, my best laid architectural or design scheme that handled the 80% happy path case beautifully and elegantly has been exposed for potentially disastrous weaknesses when questioned by someone who knew less about the situation, but asked the right questions to prompt me to realize the problems before it was too late.


Questioning Disincentives

With all the above benefits (and many more not listed) of an environment that fosters asking and answering of questions, why is this not always done? The reason is that there is also a list of disincentives for such an environment. These vary between individuals and organizations.

Rudeness

One significant disincentive that prevents or reduces good questions is fear of a rude response from the person being asked. Unfortunately, there are some pompous developers out there that no one really likes to ask questions to because of the price paid in terms of humiliation, degradation, and mocking. For example, a colleague told me of the time he asked his technical lead a question and the response was a biting, "RTFM."

Busyness

Another deterrent to asking questions is the perception that the person being asked is already too busy to take the time to listen to and ask questions. This is unfortunate because even though it is often true that those with the most answers are the most busy, it is also true that it is typically more efficient to invest a little of their time in helping others continue making progress.

Unintelligible Answers

Even when a developer has the best intentions of answering questions that he or she is asked, if that developer is not good at articulating answers at the appropriate level, this can be discouraging to those asking the questions. The better and more succinct the answers, the more likely it is that the person asking the question will gain the benefit needed.

There's No Team in 'I'

Many organizations have their compensation and rewards structures set up to measure and reward individual performance with little to no regard for overall team performance. Although I believe there does need to be some facet of individual accomplishment measured and rewarded, it is also true that no amount of individual success makes up for a team failure. It can be difficult for a well-meaning developer to sacrifice his or her ability to meet an individual deadline in order to help someone else meet their individual deadline, even if the latter deadline is more important in terms of overall priority.


Improving the Questioning Culture

Because there are so many benefits to encouraging the free flow of information at odds with so many disincentives for asking and answering questions, it is important to take steps to foster the questions and answers.

Individual Welcoming of Questions

Individuals who have the appropriate knowledge and experience can make it easier for others to ask them questions. Words, body language, and actions can indicate an interest in answering the questions. It is important to really listen to the questions and often a good idea to wait until the question is completely out before starting with the answer.

Reward Team Performance

Organizations that reward team performance in addition to individual performance and stress team goals are more likely to have an atmosphere of collaboration. The idea here is to change the workplace from being a "me against them" environment to a "we're all in it together" environment.

Reward Correct Prioritization

Related to rewarding team performance, an organization will tend to see better performance when it rewards individuals for accomplishing the highest priorities first, even if it means sacrificing their own task's timely accomplishment to make sure that someone with a higher priority task accomplishes that task.

Sharing Goes Both Ways

It can also help to have more experienced developers admit when they don't know something or have learned something from others or from their own mistakes. I have seen repeatedly where a senior, highly experienced software developer has done just this and almost immediately led to a more open, knowledge-sharing culture. If all developers feel they are contributing, they are all more likely to gain the required confidence to more freely admit when they don't know something and to seek out help.


The Questioner Can Help

People are more willing to help and answer questions when they are appreciated and do not feel their time is wasted. Here are some steps that can be taken by those asking the questions to encourage a more collaborative atmosphere.

Find Your Own Answer

This may seem contradictory to this entire blog post, but it is true that one can ask too many questions. As children and as adults, we often need to learn some things for ourselves. As developers, we particularly need to hone the ability to solve problems and to think critically about design, defects, and so forth. The real trick here is to know when to stop wasting time trying to find the solution for ourself when we could be much more efficient by simply asking someone else. Although there is no single answer because it depends on the level of experience and on the question itself, I feel that I have become better at this over the years.

Carefully Articulate the Question

Many developers want to help others, but the performance and other disincentives mentioned earlier make it more difficult to do so. The person seeking new information can reduce this cost to the person answering the question by carefully articulating the question and spelling out potential solutions or answers that he or she has already ruled out. This articulation of potential solutions and why they don't work not only demonstrates that the person asking the question has put some effort into it, but may also jog something in the mind of the person being asked the question.

Avoid Asking the Same Question Over and Over and Over Again

Another way the person asking questions can save the time of the person answering the questions is to reduce the number of times the same question is asked. Taking notes can help with this. I have even been known to e-mail myself these notes or save them to a text file in my home directory so that they are easily searchable later. Another useful technique here is to ask the question when you are ready to make use of it and/or apply what you've learned. If a question is asked before one is ready to use it, it is more likely that the answer will be forgotten before it is used. I find that I remember best what I actually do as opposed to what I read or hear.


Conclusion

An organization that fosters the appropriate level of developer collaboration has a competitive advantage over organizations that do not foster or even discourage such collaboration. There are many things individuals can do on both the receiving and giving end to improve this, but the organization can also take steps to reward behaviors that lead to better knowledge sharing, increased confidence, and more timely delivery of quality solutions.

The Problem of the Open Source Commons: Harsh Economic Realities of Open Source Software

The apparent ultimate fate of Sun Microsystems may be the most obvious example of the difficulty associated with earning significant revenues developing and sponsoring open source software. A particular open source product may be considered highly valuable by many users who, given the appropriate license agreement, never actually back up this perceived value with any type of monetary compensation. This touches on a central debate about open source licenses that provide software with very few restrictions on end use and do not require any type of payment versus open source licenses that restrict end-user freedom to a certain degree and require certain payments as a form of acknowledgement of the value received with use of that open source product.

As an end user of an open source product, I obviously prefer no strings attached and no license fee required. However, as a realist and as someone who is paid for at least some of his own software development, I do understand the desire and even the need for those who contribute significantly to open source to be compensated by those who use that open source.

I touched on this a little bit when I questioned which single entity (or even consortium) would be willing to pay Oracle for MySQL the same price that Sun paid for it (or even in the same ballpark). My speculation then is that MySQL is worth far more to a wide, diverse collective/community than it is to any one owner (except perhaps Oracle). The reason for this is that while MySQL is a heavily deployed database, it still does not garner the types of revenues most entities would need to justify its expensive price tag. This is a single example of the problem of the open source commons -- many of the products are highly valued by their users, but without any or with too little monetary compensation to reflect how valued these products truly are.

Rightly or wrongly, "value" is often measured in terms of dollars. The phenomenon of modern day open source software (not all, but a large and growing portion) is that this basic tenet has been largely ignored. We have enjoyed over the past several years access to many fine open source products in which we have to give absolutely nothing back. Some of us are old enough to remember that it wasn't always this way and is in many ways a recent phenomenon. Others in our profession are young enough to have never known differently. To them, it may seem strange to have to pay for open source.

Regardless of how old or young we are, most of us have gotten used to freely available software such as the JDK implementation, the Spring Framework, a host of useful Apache Software Foundation products, a host of Sun-sponsored products (NetBeans, GlassFish, MySQL, etc.), Eclipse, and on and on.

We are grateful for those who spend many hours contributing to these fine products, but often not grateful enough to actually financially support the same products. I try not to be too hard on myself for this; in many ways it is human nature to take the best deal you can get when it is offered. No laws are being broken (assuming the license allows for free use) and my little contribution wouldn't make a difference anyway. Besides, why would I pay for something voluntarily when I can have it for free?

The above paragraph summarizes the harsh economic realities of the open source software development world. With thinking like that contained in the paragraph immediately above, how can one expect to make enough off of open source development to live on other than via corporate sponsorship (like SpringSource, Sun, etc.)?

There have been several recent online events that have made this problem of the open source commons even more apparent. I believe the tough worldwide economy has accentuated the problem of the open source commons. One of the banner examples of what's good about the "open" world, Wikipedia, is currently prominently featuring a plea for financial contributions.

In a recent post called Funding Clojure 2010, Clojure creator and primary contributor Rich Hickey lays out a firsthand account of the effects of the current prevailing treatment of open source software by its users. I currently don't use Clojure, but it is still remarkable insight into the challenges of making money developing open source and well worth the read even by those not interested in Clojure.

A few months ago, the creator of and primary contributor to JFreeChart posted on his blog that he had accepted an employment contract because of difficulty making a sufficient living selling copies of the JFreeChart Developer Guide. Even with this setback, I was pretty impressed that he was able make a living for seven years. It seems to buck the trend of most open source development not sponsored by corporations who sell software.

One of the biggest problems is that many people think that "open source" and "free" are the same thing. It is true that the trend seems to be moving toward open source products being free of cost as well, but the distinction of "free beer" versus "free speech" is still important. It is important to distinguish between free of cost (gratis) and free of usage restrictions (libre) to understand that one might still pay for an open source product just as he or she would for a closed-source product.

I believe that open source development and use is at a crossroads. The open source development world is facing its own tragedy of the commons. We essentially need individuals and users to do something that does not seem immediately in their self interest (paying for a product that in no way requires them to pay for it) for the greater good and their own long-term good (because of the continuing viability of freely available open source). The problem is that many of us would rather that everyone else pay for it so that we don't need to.

These "tragedies of the commons" are difficult to resolve because they do pit individual (and often short-term) self interest against long-term community benefit. But, just as with other problems of the commons, if we don't find a way to do something about it, the true tragedy will be the loss of benefit to the entire community.

oerr: Oracle Error Tool

The Oracle Error utility (oerr) is a handy tool that most Oracle DBAs are likely well aware of, but I have found that many developers are not aware of. This is one of those quick and simple tools that belongs in the category of Faithful Old Development Tools that I have blogged on before.

The oerr tool is an awk-based tool available on Unix and Linux as part of Oracle database installations. The tool is simple to use and provides a brief description of the cause of a particular Oracle error code and an action or multiple actions one can take to address the database error.

To use the tool in a Unix or Linux environment with an Oracle database appropriately installed, one need only run the command like this: oerr AAA NNNNN where oerr is the command, "AAA" represents the Oracle error code prefix (such as "ORA" for all Oracle error codes beginning with ORA-), and the "NNNNN" represents the numeric portion of the Oracle error code. For example, if the Oracle error ORA-01002 is encountered, the command oerr ora 1002 will print out the likely cause or causes of this particular error along with an action or actions to take to address the error.

The handy awk-based oerr tool is not available with Windows installations of Oracle database. However, there are numerous online listings of the Oracle error codes with their causes and actions (see some in the "Additional Resources" section below). There are also variations of the Oracle-provided oerr tool available that do run on Windows. Examples of these include Perl-based Windows oerr for Oracle, SQL-based OERR for Windows, gawk-based oerr "tool" for Windows, a Java-based approach, the Firefox browser add-on oerr - Oracle Error Code Lookup and many web-based tools such as Web Oerr 11g.


Conclusion

The simple-to-use command-line oerr tool can be useful for quick determination of what is causing a particular Oracle error condition and the possible action or actions that can be taken to remedy the situation.


Additional Resources
⇒ oerr
⇒ Oracle Wiki - oerr
⇒ Oracle Messages and Causes
⇒ Ora-Code
⇒ Ora-Error!
⇒ Oracle Error Codes
⇒ Oracle Error Codes
⇒ Web Oerr 11g