The Dreyfus Model shows the 5 stages of skill acquisition possible through experience of a subject.

Created by Hubert and Stuart Dreyfus in 1980 while researching AI, the model was popularized by Dr Patricia Benner in the mid Eighties in her work on the Nursing Crisis in the US. Over the last few years this model has been resurrected in the Software Industry, primarily by Andy Hunt of Pragmatic Programmer fame.

The graph shows that in the Software Industry (as with all subjects), most people achieve a level of ‘Absolute Beginner’ or ‘Competent’, with few moving to ‘Proficient’ and fewer to ‘Expert’. The graph also reflects that as you move up the model the need for rules and best practices diminishes to the point where they actually become a hindrance.

With the huge shortfall in supply of Software Developers combined with the quality issues our industry faces, surely it is better to keep the small percentage of people at the top of this model rather than move them on to management? (As so often happens.)

I caught up with Andy Hunt at the recent Better Software Conference to ask him to discuss this and explain further how this model applies to mentoring team members and where ‘best practices’ fit.

Residents living in a city-owned apartment complex in Nottingham, England, were locked out of their homes on Tuesday of this week after a new security system was installed. Property manager Nottingham City Homes was installing security upgrades, including steel doors and “improvements” to the electronic entry system. Some of the residents were unable to get in after the upgrade, and Nottingham City Homes blamed a “software glitch” for the problem.Resident Jordan Gunn said: “My partner has been locked out several times. He has had to come round and throw pebbles at my window.” Good job she doesn’t live on the 25th floor. Not to worry, after the company apologized for the problems, they said that they should all have been fixed by Thursday. Hopefully it didn’t rain during the intervening two days. Oh wait, it’s England.

Verizon blamed a software glitch this week for the fact that it published approximately 12,500 unlisted phone numbers in a Washington County, MD phone directory. The company stated that it is taking steps to make amends to affected customers, anywhere from changing people’s numbers to paying up to $1,000 towards the installation of security systems. After the glitch was discovered, Verizon managed to stop 95% of the directories from being distributed.In a statement, Leigh A. Hyer, vice president and general counsel for Verizon’s Mid-Atlantic North Region said “We very much regret what has happened and want to make it as right as possible.” However, it turns out that Verizon is not required by law to keep unlisted numbers out of the directory. Hyer added: “It is a service we sell … it’s not a guarantee.”

After reading several blogs and comments on the demise of Java, I felt compelled to post some interesting facts.

Only a small percentage of developers go to conferences like JavaOne. These people constitute the majority of those who read, write and comment on blog sites and they are the first-adopters of new technologies and languages. These people are enthusiastic evangelists of new and cool technologies fueling, for example, the rise of Dynamic languages (which I applaud). But these same folks can be vocal complainers, ignoring possible work-arounds of existing features in languages such as Java, and predicting the death of Java. For many developers, these dire predictions can inspire fear for their jobs, compelling some to prematurely drop Java, further perpetuating the rumor that Java is indeed dying.

Maybe there are too many frameworks? Maybe Generics were an overly complex feature to introduce and maybe Closures will be too? It is hard for Sun to sustain the velocity of new features every year, and maybe this is a good thing that they do not. – It gives people breathing space.

It is impressive that Java has been consistently popular for over 12 years (Ruby was created in 1995, but only really became popular once David Heinemeier Hansson released Ruby on Rails in 2004). In our industry it’s impossible to predict how something will be used in a decade and maybe we shouldn’t try. Have Sun got carried away with the popularity of Java and tried to make it into something it wasn’t designed to be, creating an overly complex beast? Are these proponents of Java-Death simply Java gurus that who are just seeking perfection?

Do I think Java is dying? – No way! Each programming language goes through changes: it’s all about evolution. [Most] people do not program in Assembler anymore. The next generation of languages will build on the limitations (mistakes?) of the past and be more suited to the hardware and designs of the future. For example, concurrent programming is very difficult to manage in Java so maybe laguages such as Fortress will be indicative of things to come. With multi-core processor machines the norm, the industry will demand that future software development take better advantage of this hardware advance.

So here are a few facts:

• The JavaOne Program Office announced that there were around 15,000 attendees at JavaOne this year. (There was also a lot of negative discussion regarding JavaOne, but this criticism was really about the show rather than Java–see my comment on Jason Lee’s: Postmortem on JavaOne 2008)

• One of the most impressive announcements at JavaOne was that Sun have made a 68% performance increase running Java 5.0 against Java 6 update 10. On the same hardware (showing their commitment, at least, to the JRE)

• Released only last month, Effective Java 2^nd Ed by Josh Bloch is ranked #291 of TOTAL book sales at amazon.com and #8 in the Computers & Internet sub-section

• Without too much analysis (i.e. just typing in the flowing keywords in Dice.com) current vacancies for the following are:

Java     15,337

Ruby    818

C++      7,633

C#        7728

Python  1,395

Perl     5,463

Cobol  1,131

Assembler 196

- I was just interested in these last two

Note that I haven’t even commented on the millions (billions?) of dollars organizations have spent on applications written in Java. Are they about to drop and rewrite these applications in the next generation of languages?

After much thought, we have decided that selling Java development tools is not a viable business model for us. Several recent events have helped us reach this conclusion:

• At JavaOne this year, free tools completely dominated the sessions. The exhibit hall was sparsely filled, and while we saw lots of interest in free t-shirts and spin-the-wheel games, there wasn’t much interest in the vendors’ products themselves.
• Our friends at Agitar have begun to wind up operations. It was interesting to watch them go through several iterations of their business model but ultimately they were unable to find anything that gave them a reasonable return.
• Sales of our own product have been slower than we had anticipated.

Ironically, I was putting together my own budget for next year and realized that there just aren’t any software purchases on there. We’ve bought a few specialized pieces of software - Mathematica for the index work; JProfiler for performance tuning and Atlassian’s Jira and Bamboo - but we’ve moved to free tools for everything else. Atlassian has insane maintenance prices, so if anything happened to Jira or Bamboo, we’d almost certainly replace them with Trac and something like Hudson.The good news is that we are absolutely committed to the Enerjy product and, therefore, with immediate effect, the Enerjy plugin for Eclipse is available at no charge. Our goal is to become the most widely used static code analysis tool in the Eclipse world by providing a wide but pragmatic ruleset and the same level of seamless integration that you’ve come to expect from Enerjy. We have great plans for widening the ruleset and making the configuration wizard smarter to help manage all those extra rules.So, how are we going to stay in business if the product is free? Well, we run a very tight ship here, and we have sufficient funding to continue for the foreseeable future. Moving forward, we have had success in the past providing expert advice to organizations on code quality. With the additional data and experience we have gained from the Enerjy Index, the plugin and Bugpedia we believe that we can offer unique, technology-based consulting services to companies seeking help with code quality issues.To those users who purchased the product after April 1, we will be contacting you to arrange a refund of your purchase price.If you have any questions please post them here or, if you prefer, contact me directly at mark_dixon at enerjy.com.

As if the financial world wasn’t in enough turmoil already, it has been revealed that programmers at debt rating company Moody’s made a “coding error” that overrated several debt products in early 2007. The products affected were targeted at institutional investors, and after the error was corrected, their ratings dropped from the top triple-A designation by “several notches”. It is estimated that institutions that invested in the previously top-rated debt products will have lost up to 60% of their investment.Oh well, it’s only money.

The first page of the preface of this book made me wince! Not because the book is bad, far from it! The immediacy of Scott’s insight into the pain of software development can only come from someone who has been there and experienced the trials and tribulations of project failure (more than once).I was expecting this to be yet another book on Design Patterns, but it really isn’t. This book attempts to look deeper into questions that cannot be easily answered and suggests a road map to evolve the profession of software development. It concentrates on practices, principles and disciplines that developers should follow when creating software, especially when thinking about how to implement features. It covers a wide range of practices, including analysis, refactoring, testing, and looks at how existing patterns should influence our design decisions.The appendix includes some very good examples of common design patterns. Different styles are applied to each pattern to teach or remind us what type of problem each pattern is used for. UML diagrams, procedural code alternatives, non-software analogies and basic OO code for implementation are included for each pattern.Since so many of us have to deal with legacy code bases, it’s always helpful when a book like this addresses that issue. Scott mentions hearing comments such as “this code is too hard to unit test,” “unit testing takes too much time” and “too many permutations to unit test.” He explains how these all point to design issues, and that leads into a great chapter discussing refactoring.Why should we refactor if the behavior does not change? This and other similar questions are covered too, explaining the concept of technical debt and the frequency of developer burnout: “Decaying, hard to maintain software will disable a development team faster than anything I know.”I would thoroughly recommend this book to any developer, however experienced or inexperienced, who wants to understand more about design patterns and how thinking in a design-driven manner can evolve our profession.I caught up with Scott at SD West, to ask him a few questions about his book.

The quiet market town of Banbury, Oxfordshire in England is not a place you would expect to see in the news very often. But, according to the Banbury Guardian, a bingo cashier in the town’s Gala bingo hall was jailed this week for stealing approximately $32,000 from her employer.Apparently, the bingo hall uses a swipe card system, called Buzzcard, that allows patrons to load money onto the card and use it to store winnings. When Emma Meechan, the cashier in question, discovered a misfeature in the system that caused about $335,000 to be mistakenly loaded onto some of the cards, she took advantage of the glitch and pocketed some of the money. Meechan was sentenced to serve 8 months behind bars.

I’m excited to announce the launch of a new site, Bugpedia. Creating the Enerjy Index threw out a lot of fascinating data and I was frustrated that I didn’t really have anywhere to put it. For example, if you follow this blog you’ll have seen Rich’s post on our analysis of Cyclomatic Complexity. Well, just for a start I’ve got an updated version of that graph along with similar results for 200 other metrics to share. We thought for a while and came up with the idea of a wiki to contain all the useful information we, or anyone else, had about software code quality and, in particular, bugs. I’m hoping that Bugpedia will become a repository for bug patterns (i.e. common types of bug such as forgetting to close streams in a finally block), specific bugs (e.g. API’s that are often misused) and the tools and techniques you can use to avoid them.I’ve set it up as a wiki because I genuinely need your input. I can’t catalog the world’s bugs on my own! Much of the content on the site currently is about Enerjy because I wrote it and that’s what I know. I’m hoping it won’t stay that way for long though, and so I’ve intentionally left the wiki wide open to make it as easy as possible to contribute. Even if you just want to post a stub article as a placeholder for information you’d like to see, that would be great. I haven’t tried to hide the Enerjy link, but this is not supposed to be an Enerjy corporate site. Enerjy are providing hosting and bandwidth but it’s my site not theirs. I reserve the right to edit or remove content that doesn’t fit with Bugpedia’s mission but I’m not going to censor content that is critical of Enerjy or talks about other tools - commercial or open source. In fact I’m going to be creating some content for FindBugs because I believe it is an important tool in the Java ecosystem and Bugpedia would be incomplete without it. So I’ll mention our tool where it makes sense but I invite you all to do the same and if you see any content that you think is too commercial - well, it’s a wiki, you know what to do!Please go take a look and let me know what you think.

Approximately 250,000 cell phone subscribers lost service for most of Tuesday this week in Vermont and neighboring states. According to the Brattleboro Reformer, a “software issue” caused the problem, which caused the loss of Unicel’s cell phone service from about 4:00 am until 2:30 in the afternoon. Public Relations Manager Miriam Svobodny said the outage affected customers in Vermont, New Hampshire, New York, Maine and parts of Massachusetts. She also said that the breakdown was the largest of its kind in the past 10 years. Apparently, users were still able to make 911 calls during the outage.