Last week’s “Don’t Worry, Be Crappy” post focused on some managers who may push for a quick release in place of quality initiatives. Most developers believe that these goals are not mutually exclusive, and have ideas on how things could be done better. However, many are reluctant to even mention these ideas to their managers for a number of reasons including:1) The “this is how we’ve always done it” philosophy;2) They have seen management reject similar ideas in the past, and therefore believe they would be wasting time even bringing their ideas up;3) Intimidation or lack of confidence or experience to “sell” the idea to management.At SD West, I asked some of the speakers, who are also experienced developers and managers themselves, what advice they would give someone who has an idea and wants to sell it to their manager.

If you were in Hastings, MN, this week, and you needed emergency services, you could have been in trouble. A software problem at the Dakota County dispatch center meant that some 9-1-1 calls were not being answered. Callers heard a normal ringing tone, but the calls were not being put through to an operator, they were dumped into an “abandoned calls” queue instead. Until the problem is fixed, the dispatch center has issued a different, slightly less memorable, number for people to call.Meanwhile, in Port Townsend, WA, it was announced this week that last year’s Rhododendron Festival Queen should not have even been crowned. Dana Perkins, a high school junior, spent the year as Rhody Queen, only to find out that the scoring algorithm failed to add the score from one of the judging categories. The real queen should have been Chelsea Benner, Perkins’ classmate. Who knew?Finally, to my old home town of London, England, where the “congestion charge” - a toll that is levied on anyone who wants to drive in central London during the day - has had mixed reviews. But when Graeme Ellis went online to pay the toll, he was a bit surprised to receive 500 receipts for the transaction. That was bad enough, but the second time he paid, he received 3,000 receipts - all for the same transaction. Service provider Capita says the problem has been found and fixed.

We are commonly taught to create objects using the JavaBean pattern, where for every variable there is a corresponding getter and setter, or by passing in attributes to the object’s constructor on creation. For example:

Employee emp = new Employee("name", "some address", "city", "state",             employee_number, salary, department, … more arguments);

Not only is this not ideal to read, you must remember to pass the values in the correct order. Even type safety will not help you if, for example, you interchange the city and state arguments. Also, if the Employee class has only two mandatory fields (name and employee number) the developer must add null entries to fields they do not want to set at creation time.This method also violates the Open/Closed principle (PDF link) where classes should be open for extension but closed for modification – thus to increase functionality, add new code (via abstraction), rather than changing old code.Using a Builder Pattern allows you create the same object in the following way:

Employee emp = new Employee.Builder("Rich Sharpe", 32)            .address("1 Java Way")            .city("Javaland")            .salary(12000.00)            .department(AccountsDept)            .build();

Not only is this more robust than the JavaBean pattern or the long unwieldy constructor, but the creation of this object is now far more elegant to read.Here is the partial Employee class:

public class Employee {  private String name;  private String address;  private long employee_number;  private double salary;  public static class Builder {    private String name;    private String address;    private long employee_number;    private double salary;    public Builder(String name, int employee_number){      this.employee_number = employee_number;      this.name = name;    }    public Builder salary(double salary){      this.salary = salary;      return this;    }    public Builder address(String address){      this.address = address;      return this;    }    //Additional setters here...    //Finally add the build method    public Employee build(){      return new Employee(this);    }  }  private Employee(Builder builder){    this.name = builder.name;    this.address = builder.address;    this.employee_number = builder.employee_number;    this.salary = builder.salary;    //Copy remaining data from Builder to Employee...  }}

Create a static ‘builder’ class within your class and provide individual setter methods. Finally add a ‘build’ method that returns an instance of its class as a parameter to a private constructor of the class you wish to build.If a specific exception needs to be thrown, then the private Employee constructor and public build() methods can handle this (remember IllegalArgumentException and IllegalStateException do not have to be specifically declared in a throws clause).Usually this type of creation pattern is used when an object will not change during its life. I chose to create a User class as for this example as a huge benefit of this type of creation is that the object is immutable and therefore thread safe.Although a user may change some attributes; such as their last name if married or address when moving, these are so rare that it may be better to just delete the current object and create another as object creation is very inexpensive and one retains the benefits of an immutable object.

By chance, a couple of space-related stories crossed the Glitch Watch newsdesk this week that caught our eye.The International Space Station has been featured before on Glitch Watch. But last week, a $200m Canadian robot called Dextre (that’s French for Dexter) was paralyzed in space owing to a problem with the software that controls the heaters needed to keep its joints working in space. The robot is supposed to avoid the need for actual people to take space walks to fix problems with the space station. Ironically, if the software update currently being uploaded fails to fix the problem, astronauts from the space shuttle Endeavour will need to make a space walk to disassemble Dextre.Meanwhile, from even further afield, Jupiter, to be precise, NASA’s Cassini orbiter suffered an “unexplained software hiccup” of its own last week. Collecting space dust from the ice plume of Enceladus sounds like the stuff of science fiction, but that is exactly what the orbiter was supposed to be doing last Friday. Except that, thanks to the “hiccup”, the orbiter’s cosmic dust analyzer failed to transmit data to the onboard computer just at the crucial moment when the craft was flying through the plume. Engineers have until August to fix the problem: that’s the next time the craft will be close enough to the ice plume to attempt the fly-by again.

Back in 2006, Guy Kawasaki famously blogged “Don’t worry, be crappy. An innovator doesn’t worry about shipping an innovative product with elements of crappiness if it’s truly innovative*.” This will send a chill down many developers’ spines as the cost and, let’s be honest, hassle, of reworking ‘crappy’ code is enough to demotivate anyone.Other executives may hear this and, knowing how successful Kawasaki has been, want to emulate him. But are time to market and good quality code in software applications mutually exclusive?(*To be fair, Kawasaki did go on to say “I’m saying it’s okay to ship crap–I’m not saying that it’s okay to stay crappy. A company must improve version 1.0 and create version 1.1, 1.2, … 2.0.”)I asked some of the speakers at SD West their thoughts on this issue.

Last summer, the Hampton Roads Sanitation District, which manages the “wastewater” of 193,000 homes in Newport News, VA, implemented a new billing system. Now, 6+ months later, some of its customers still have not seen a bill since that time. The District says that it will take until at least this summer until the problems are cleaned up.Talking of cleaning up, we turn our attention to Nashville, TN, where the Tennessee Ethics Commission has been having difficulty with its new electronic filing system. Elected officials in the state are required to file with the Ethics Commission, disclosing any potential conflicts of interest. It seems that some of those filings have gone missing, exposing the alleged non-filers to a potential $10,000 fine.Finally, to Milwaukie, OR, where a Canada goose flew into a power pole last Saturday, knocking out power to a sewage treatment plant. Unfortunately, the fact that the Oak Lodge Sanitary District wastewater treatment plant only lost some of its power confused the controlling software, which failed to switch to back-up power. As a result, about 93,750 gallons of raw sewage was dumped into the Willamette River. The goose, by the way, did not survive.

Last week I was at SD West in Santa Clara, and on Tuesday night I had the privilege to attend Stelligent’s round table event. Around 40 people were there including industry celebrities such as Alistair Cockburn, Neal Ford, Scott Ambler and Jeffrey Fredrick.An hour was spent on the subject: “What is Agile?”; an agreed definition for which eluded everyone (even with this august group in the room).Neal Ford asked people to define agile in two words: “have fun”, “speedy delivery” and “driving quality” were popular answers. Someone commented: “selling the quality helps get agile projects underway.” Andy Glover quickly responded, “quality doesn’t sell! Speed does!”This is an interesting point. At first, the idea of focusing on speed may seem to violate many agile principles. But the speed comes from injecting quality into the development process. At first, teams new to agile techniques will be slower at producing artifacts for the customer because agile often requires a change in culture, which takes time to adapt to. However, the quality built-in will ensure that over time, releases will be quicker as the foundation of the software is a much more robust.Many times we have seen products released too soon, because time to market has been considered the most important factor, but over time code has been ‘layered’ onto this brittle foundation, causing cost to be incurred later, necessitating refactoring (or even completely re-writing) these products.The two words I would use to describe agile are “better communication”. This is something I believe is a constant in any team using agile practices for any length of time. Whether it is pair-programming in XP or stand up meetings in Scrum, communication between developers has improved with the result that (a) most team members are aware of what issues are cropping up in other parts of the project; (b) they have a better understanding of the whole system and the business benefits of what they are producing; and (c) More synergy is created and morale within the team is almost always improved.By the way, the 2008 Jolt Awards were presented at the conference, and our congratulations go to Stelligent as Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall (CTO), with Andy Glover (President) and Steve Matyas book won the Best Technical Book category.

A few weeks ago, I gave a presentation on Quality and Metrics at the Phoenix Java Users’ Group. The presentation covered how source code metrics can be used to drive quality initiatives in development teams. I also demonstrated a three-stage implementation of metrics tools – Static Code Analysis, Code Coverage and Dependency Analysis tools that can help developers rout out buggy code fast.One question from the audience was: “As a developer, how can I respond to a manager that wants all the features, excellent quality and everything completed by the required deadline, when I know it is not possible and almost all our budget has been used?”That experience reminded me that Bob Martin, CEO of Object Mentor, was asked the same question last year at Agile 2007. Bob clearly felt passionate about this subject, indicating that developers need to be more professional and responsible, and that a worthwhile manager should know better than to even make the request in the first place.So, when I caught up with Bob at the SD West conference in Santa Clara, CA last week, I thought it would be interesting to ask him to comment on this very question for Enerjy.tv.

Students at Notre Dame de Namur University in Belmont, CA, have been struggling with automated dorm room doors that don’t respond to their card keys owing to software problems. According to junior Matt Baza, for a whole weekend “they had to prop the doors open.” Kind of defeats the object of the security doors in the first place, it seems to me.Talking of students, in James City, VA, more than 500 incorrect transcripts for high school seniors were sent to the colleges they had applied to thanks to a “software glitch.” Oops. Henry Broaddus, dean of Admissions at the College of William & Mary said “It’s really not a bad thing and it’s an easily correctible mistake.”Finally, to the slew of stories surrounding Leap Day - the once-every-four-years-or-so occurrence of the date February 29. As you can imagine, there were several stories with this theme, the best covered of which was the failure of United Airlines’ Easy Check-In kiosks, which caused check-in delays but nothing worse. More delays were encountered in South Carolina DMV offices across the state after their system choked on the unusual date. According to local news Channel 7, “Friday morning a new software program was written” that was up and running by 1:00 pm. Now that’s what I call agile!

Have you ever noticed how restaurant menu writers seem to speak a different language to the rest of us? Chefs don’t pour gravy on our food, they drizzle a demi-glaze. They don’t offer us a cheese plate, they offer us a degustation.That’s all fine and well when I’m out at a fancy restaurant and some element of mystery is a welcome part of the experience. But when I’m trying to import an ICS file into my calendar, I don’t expect to be similarly befuddled. Is there any reason, I wonder, why this dialog box couldn’t have said “You are about to import more than 250 calendar entries. Continue?”