A large part of improving the quality of software is knowledge sharing (indeed it is one of the basic tenets of Lean). In most organizations when a bug is submitted it is usually delegated to the developer who wrote the original code.

Paul Pagel’s blog discusses how his team tackles bugs in development and production.

I especially liked:

“[The Production Support Resource] seems a lot like a silo to me. Everyone should be able to do production support on any system. I should have to, because it is a perspective of the system that is important to have. In response to this, we came up with a system of triage. Each day of the week is assigned to a specific developer. If a support item comes up, it is the job of the triage developer to respond to the client/customer we are working on it.”

This is such a simple way of sharing knowledge and keeping tedium away from a designated ‘support engineer’. However, managers may originally question this for several reasons including:

1) A faster response time will occur if the original author fixes the bug. – This is short-term instant gratification. After a while the difference in time for a bug fix between developers (of similar skill level) will most likely be negligible.

2) The author is an expert in that area. – This allows others to increase their skills knowledge, benefiting the entire team. What happens if the original author is out sick or even leaves the company?

3) We’ve always had a designated Support Engineer, everyone knows who to go to. – This is a Command and Control’ management style and in most cases leads to lower team results. Managing by Facilitation and allowing the team to assign work themselves has proved more motivational to the team and resulted in higher quality artifacts.

I strongly believe that this method is more beneficial to the team, evolving individual’s skills and ultimately benefits the customer.

One evening after sessions at the Better Software Conference, Dan North and I got into a discussion regarding the phrase ‘Best Practices’ and concluded that this term was actually a misnomer.

Let’s take a non-software analogy; wearing a seat belt in a moving vehicle.

With all the studies that have been performed over the years, one may believe that wearing a seat belt is a best practice. However, for a very small minority of cases, it is not the best thing to be wearing a seat belt. EMS and Police personnel in some countries are not required to wear seat belts, because they can respond faster unhindered by a seat belt. Also some drivers, like those in the TV show Ice Truckers, do not wear seat belts because they need to be able to jump out of their rig the moment they hear ice beginning to crack. These may be minority cases and for over 99% of us it is a good practice (never mind a legal requirement) to wear a seat belt–but it is not a Best Practice.

When we talk about Best Practices we really mean ‘the current best thing to do in a particular context’. When coding, depending on the situation, we try to solve an issue using some practice we know works effectively. Wait! Haven’t we heard this before? Isn’t this what we use to describe Patterns? On reflection, patterns would be a sub-set of what we wish to achieve and still other ‘good practices’ will need to be enforced somehow, especially early in a developers career.

The terms ‘Best Practices’ and ‘Standards’ are also used interchangeably, especially when applied to code. This is wrong! Coding standards may be formed from current ‘best practices’ but other issues such as law and external environmental concerns may mean that the code standards are not necessarily the current best way to write a piece of code.

This is just one example of the terminology problems that needs to be clarified in our profession. I don’t believe a committee can enforce this, but terminology, over time, will become more widely used and accepted as our industry matures, as has occurred in other industries over a period of time.

Many have written about language ambiguity being one of the key issues which leads to misunderstanding requirements and that a language needs to evolve so business and IT understand each other.  I would go one step further and declare that at least two formalized languages are needed. One for the Development team for lower level issues so statements such as ‘this lends itself to a Strategy Pattern’ or ‘favor composition over inheritance’ are understood by all the team members and another for Business Analysts, Project Leaders and Stakeholders to ensure no ambiguity exists in the requirements.

IMO the first language is closer to being realized than the second. Maybe interest in UML will be rejuvenated with Microsoft’s recent announcement of UML support to be added to Visual Studio Team System providing another step towards this goal.

So I was coming back from Atlanta yesterday and, as I arrived a bit early at the gate, settled in to read my RSS feeds. I picked a spot that was far enough away from the gate not to be too crowded, while at the same time allowing me to keep an eye on the TV screen showing the flight status.After a while, I noticed that the screen, which had been alternating between the flight status and a series of Delta ads, wasn’t updating any more. Getting out of my seat to go and get a closer look, I discovered what the problem was. It was only after I checked a different screen that I discovered that my gate had changed…

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?