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.

With JavaOne commencing this week, there will be much persuasion for those not yet upgraded to Java 6 to do so.

Although not as rich in features as the move to Java 5 was, Java 6 still has benefits. My favorites include:
- A scripting engine (Rhino) for languages such as Javascript
- Wildcard inclusion in Java classpaths
- JTable sorting, filtering and highlighting in Swing
- Zip files no longer have a limit on entries (was 64k) and include long filenames
- Java DB included (based on Apache Derby) with support for JDBC 4
- GIF support for image I/O
- A limited HTTP Server

A few nice API additions include:
- Deque (Double Ended Queue), intended to replace Stack in the Collection Framework
- NavigableSet and NavigableMap, ideal for dictionary types
- Methods such as getFreeSpace() and getUsuableSpace() available on drive partitions

Performance improvements have been seen on certain environments such as JBoss running on Linux, just by upgrading to Java 6.

For a full list of enhancements see this.

I spoke with Jason Hunter about some of these new features, Java’s popularity and the much-debated issue of including Closures in Java 7. Here are his thoughts…

Ford Motor Company announced this week that it will recall 65,000 Volvo V70 and XC70 cars because of a problem with the software that controls the side-impact air bags. Apparently the recall applies only to cars in Europe.

According to Volvo’s spokeswoman Maria Bohlin, the software needs to be “adjusted” because the airbags do not deploy fast enough. She said, “We will send letters to all the owners of the affected cars and tell them to take the car to a mechanic to get this upgrade.”

I wonder how long it will be before software upgrades like this can be automatically downloaded to the car with no need to bring them to a “mechanic.”

Tom and Mary Poppendieck are two leading evangelists of Lean software development who share their experiences at conferences on a regular basis. Their first book was an excellent introduction to lean principles and tools, and this book continues the theme by explaining the concepts in the real world, and how to implement them.

Firstly, let me say that, in my opinion at least, this is a book for managers who want to find out more about lean processes, rather than being aimed at software engineers or architects. And in this context, it does very well. The theories and concepts described are well laid out in individual chapters that cover: Principles, Value, Waste, People, Knowledge, Quality and Partners. The book quickly gets you thinking about how to start implementing these ideas in your own organization.

For a book that is less than 250 pages, I was surprised by how long it took me to read. This was mainly due to the large number of very good and equally intriguing references and examples that compelled me to investigate further.

My favorite chapter is “Waste,” including the description of the “Seven Deadly Wastes.” Sound advice is concisely provided in the form of often-missed principles that lead to waste, for example:

If there isn’t a clear and present economic need for the feature, it should not be developed!

Other, less obvious examples are also given such as:
Rotating/replacing staff – handoffs are a good example of losing tacit knowledge (waste)
Map a Value Stream - although not necessarily accurate, does identify waste from the customers’ perspective.

Waste is one of those concepts that is somewhat subjective, and in one part of the book there is an example of an organization that ran multiple projects to develop different versions of the same system against a hard deadline (absolute minimal functionality but guaranteed, more functionality but not guaranteed, ideal system but very unlikely to be completed by the deadline).

This can appear contradictory to a key agile principle: to develop only what you need (and indeed to a key Lean tenet, which is to reduce costs). The authors justify this by stating that one system will be implemented by the defined deadline and then something much better will be built in time for the next iteration. However in my experience, organizations tend not to have the resource available to perform simultaneous development of the same system. It is more usual to deliver to the customer as much functionality as is available by the deadline (remember that it will be working through smaller iterations) and then to implement any improvements over time depending on priority against other parts of the system.

The chapter on quality begins with a discussion of the Polaris Submarine project and moves onto a description of iterative development. Then follows details of what I would refer to as implementing quality gates, code reviews, test driven development, standards and continuous integration. More detail and an example of the benefits of CI would greatly enhance this chapter.

I would like to have seen more examples from the software industry to explain the many well laid out concepts. But some of the brief examples used from other industries hit the mark well, for example: Deadlines! Daily Newspapers and Concerts/Theatrical Productions hit deadlines constantly and consistently unlike the software industry.

I believe the best example in the book is the Rally Software Case Study, where they explain that it took 14 months to eliminate technical debt using a Strangler approach. Some of the concepts in the book read as if these are quick fixes to implement that will see a fast return. This example highlights the fact that process management change does take time to take effect.

Overall, I consider this to be a great book for laying out the principles and how to begin to implement them, especially for managers wanting to find out more about lean software development. It covers the concepts well and provides excellent further reading resources.

The Poppendiecks’ companion site provides an interview about the book. Other useful resources for anyone who wants to learn more about Lean are the Yahoo groups leanprogramming. and leandevelopment.

Glitch Watch is a bit abbreviated this week by virtue of the fact that I am on the road which severely limits the amount of time I have available to sort through the mail bag. However, one story did catch my eye this week. Irish airline Aer Lingus inadvertently advertised €5 (about $8) business class seats from Ireland to Boston. The normal business class seat price is apparently €1,775 (about $2,765) each way.

Between 7:30 am and 9:00 am when the “glitch” was discovered, about 700 tickets were sold, including some to Aer Lingus employees themselves, and the airline now has the problem of what to do with them. Initially, they canceled the tickets, on the basis that it was clearly a mistake. But in the PR firestorm that ensued, the airline backpedaled and offered the customers economy class tickets. Still not a bad deal!

When investigating Lean for the first time, books and articles that give an overview of the principles and tenets of Lean can appear to be contradictory. For example many managers may question how Cease Inspections can be advocated where a basic principle of Lean is to Create Knowledge. Surely one of the fundamental reasons of Inspections such as Code Reviews is to help more Junior Developers adhere to company standards and learn better, more efficient ways to code?

I discussed this further with Bob Martin (Uncle Bob) and Jean Tabaka and they gave some good insight into what this phrase ‘Cease Inspections’ really means, even with Jean’s radical conclusion of Firing your QA department

Stillwater, MN: the Stillwater Lift Bridge got stuck in the open position for more than two hours this week after its controlling computer got “confused”. According to Minnesota Department of Transportation spokeswoman Mary McFarland-Brooks, the computer “said that the bridge was both open to boat traffic and available to motorists at the same time, which obviously couldn’t be the case.” Although strong winds were thought to have played a part in the incident, a reboot of the computer fixed the problem and had motorists on their way again.

Meanwhile, in Japan last week, Hitachi announced that they had discovered a programming fault in software used to measure the impact of earthquakes on pipes at atomic power stations. The fault allowed the software to underestimate the impact of earthquakes on steel pipes in eight nuclear reactors. Good job it wasn’t anything important. The software has been in place and monitoring the pipes since 1980. Test results using corrected software indicated that there were no problems with the pipes.

Problems with a new $3m automated trip reservation system caused difficulties last week for disabled users of Chicago’s paratransit system. Apparently, computerizing the dispatch system was supposed to make things better for the roughly 6,000 disabled people who use the system each day. But according to Pace Executive Director T.J. Ross, “it has created more problems to date than it has solved.”

Back to London’s Heathrow Airport again this week, where problems with the new Terminal 5 baggage handling system just won’t go away. The new terminal has been plagued with problems since it opened at the end of March, and on Saturday the baggage system failed, causing handlers to have to sort bags by hand.

But our favorite story of the week comes from Lee County, FL where, if you are using a TomTom to find your way around, you may end up going around in circles. It seems that there is a specific area of road that has the device confused. According to a Tom Tom spokesperson, “There is a segment of road between I-95 and the first road that crosses the route that causes an anomaly due to the manner in which TomTom’s software application processes the location of Ft Myers.” Apparently the problem has been found and fixed, and an update is available from TomTom’s web site.

When your manager says: “We expect you to write good quality code,” many people, especially junior developers, will freeze, thinking about code structure, performance, best practices, company coding standards, patterns… the list goes on and on.

At SD West, I recalled David Bernstein’s advice when writing a class. He said to ask yourself the question: “How would I test this class?” If the answer is too long or complicated, then you need to refactor the class. That seems like a good starting point for someone who is not sure where to start.

That led me to think that a good topic for Enerjy.tv would be to ask our panel of experts what one piece of advice they would give to developers when thinking about quality issues. So that’s what I did.

Wednesday last week in Lake Placid, FL, residents were warned to boil water after a computer glitch caused the town’s water storage tanks, which together hold some 300,000 gallons, to run dry. By Friday, the water was back on, and certified drinkable.

Meanwhile, at Heathrow Airport in London, England, Terri Patsalides had a long wait for her baggage. So long, in fact, that she stopped by the Giraffe Juice Bar for a coffee, and had time for four cappuccinos. However, when she got the check, she was a bit surprised to find that she had consumed £360,000 worth of coffee (roughly $720,000). Patsalides said “When I got the print-out I told the waitress that although they were very nice, I thought £90,000 a cup was a bit over the top.” According to the Giraffe Juice Bar it was “just a glitch on the computer system.”

Finally, to Portage, WI, where problems with the Wisconsin Department of Natural Resources computer system caused delays for turkey hunters trying to get their permits last week. According to Doug Williams, the owner of DW Sports Center, issuing the tags was taking one to two hours instead of five to ten minutes. “Thankfully, they’re not blaming me,” he said. Good job too. If you’re going to upset a bunch of customers, it’s probably best not to pick the ones with shotguns.