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.
No comments:
Post a Comment