Fred Brooks’s law of ‘adding manpower to a late software project makes it later‘ is one most of us have tried to prove wrong…….and failed!I was at Agile 2008 and saw an interesting session, “Breaking Brooks’s Law” from Menlo Innovations, a Michigan based Java development company. They claimed to disprove this law and demonstrated their working environment and techniques that allowed them to do so.Although the presentation was only 45 minutes, we were in the room for almost 2 hours asking questions to determine how robust their techniques were, and to gain more insight into the conditions developers work under.Menlo’s results are based on a 3 year project that the customer had a deadline to demonstrate at a show. More features were required for the show than currently in the plan. So rather than re-prioritize, Menlo decided to add more developers to attempt to complete the work. They managed to complete the Project on time with all added functionality.The environment at Menlo is quite unique. All developers are co-located in the same large room (no offices or cubes) and pair program 100% of the time - they follow strict XP practices. A scheduling team determines which projects developers work on and who they pair with on a weekly basis. So developers work with different team members and possibly different projects every week.Also, as part of the contract, the customer comes to Menlo every week to prioritize the work for the next sprint.These techniques may appear somewhat draconian (100% paring for example). I managed to catch up with the team and interview them to discuss this project further, bug rates, staff attrition rates and how Project Managers can push the message of pairing to Senior Managements/Directors (see video).I thoroughly enjoyed talking with the team from Menlo and they invite anyone passing by to stop in and take a look at how they operate. They also have an interview process which involves a large number of candidates performing a number of tasks including Pair Programming, with an appointment you can observe this too. A detailed paper about their techniques and contact details are here.

Earlier this week on Javalobby, I posted an extract from our monthly newsletter regarding our analysis of the ‘missing braces in If Statement’ rule firing and the potential bug involved.If you omit braces and use Static Analysis tools it is a problem actually finding these bugs. Why? Because you probably have the rule turned off!Having any tool tell you of violations in your code purely due to a stylistic preference will result in thousands of false positives and eventually demotivate the developer from using the tool, therefore, for the other good causes these tools promote, in this case it is probably better to switch the rule off.Hopefully Unit Tests are in place to cover these areas if static analysis is not used. The only other way to find these bugs is manual code review (laborious, time consuming and introduces human error i.e. the bug may be missed anyway) or debugger tracing.Another interesting aspect about the post was the comments. Many of those who omit braces in If Statements do so for readability purposes. Psychologically, this may mean that these developers see readability as a higher aspect of quality than possible fault-prone code. I’m not stating that readability is not important, far from it. However from a business perspective, having the code released with less faults is a higher quality perspective.

To follow from the successful launch of our free Eclipse plugin, today sees the official launch of our Service Offerings for Java Development Teams.Over the last 5 years we have been helping development teams increase the quality of their applications.From these experiences and our own experiences we have formalized a collection of offerings that can help improve code quality further.In summary our Services consist of:- An Internal Quality Code Report- Continuous Integration Services- Context Specific Standards for the free Enerjy Software plugin.More details can be found on our Services page of our website.

Achieving Project success over the last 30 years has been difficult! Reports on various studies released over the last 5 years state as little as 30% of complex projects succeed. Although this number is climbing, very large projects (300 – 500 man years) have been the least successful in succeeding, with one report in 2007 (Sauer, Gemino, Horner Reich) studying 412 projects finding no successful projects of a size greater than 200 man years. So why do we continue to undertake such projects and how can we succeed?

Eating The IT Elephant – Moving From Greenfield Development to Brownfield by Hopkins and Jenkins introduce ‘Brownfield’ as a philosophy for the evolution of legacy projects. They recognize that for the delivery of large complex problems to become repeatable and predictable some fundamental areas of the IT industry have to change.

The book is split into two parts; the first half looks at problems in large projects dealing with extending legacy systems, their failures and lessons learned – Communication and embracing complexity appears to be the biggest issues.

The Second half looks at how an Elephant Eater (a system which can consume and understand all relevant information about a project and its environment) can theoretically be implemented. Herein lies a paradox – the Elephant Eater seems to be such a large project in itself that it is doomed to failure.

That said, a lot of their concepts are very interesting such as Software Archeology, transforming Legacy code and configurations into different views and models. Also, using visual environmental models to pass information to various members of the project at different levels. So high level business overviews for Stakeholders and lower level technical detail for developers/architects. The difference being that these are actually linked, so business elements can be traced through lower levels right to the code if necessary. They even suggest utilizing Second Life for this.

Their experiences of how project managers tackle Change Management and embrace Induced Complexity is reflected in their conclusion that it is not technology that causes most large projects to fail but rather Inconsistency and Ambiguity. When projects are late, the wrong solution most managers turn to is to add more people in a last ditch attempt for success.

A common recurring theme is that there is a lack of experts in the IT industry to understand the external environmental issues and constraints that often derail large projects down the road. One solution they suggest is the ‘Site Visit’ where team members can actually have experience of the current system working to determine any issues that may not be apparent in any requirements received.

The book gives some great examples of Legacy evolving projects failing because Greenfield techniques were used. Most of these failed in the later stages and they conclude that although the solutions were elegant they were solutions to the wrong problem – namely integration failings. From their experiences they introduce the VITA (Views, Inventory, Transforms and Artifacts) Architecture.

There are a few things I would have to question.

The authors seem to believe the IT industry is somewhat mature. I don’t think this is the case at all, in fact I would go as far as saying it is still immature, especially in the development lifecycle, hence few to none of these very large projects succeeding.

One suggestion they refer to a few times is to ‘use your own language’ when discussing problems with team members. I believe that this actually causes more Ambiguity and more formal languages need to be present to evolve our profession.

A suggested approach to Pattern Driven Engineering (PDE) that is built in as part of Model Driven Architecture (MDA) is a focus of Brownfield Development. This may be fraught with danger as it is becoming recognized that early use of patterns lead to them being used as a complex solution to a simpler problem – Pattern Happy Development. An alternative would be to recognize these patterns in refactoring stages and then apply them to increase the quality of the code.

For a 200 page book there is a lot of interesting and somewhat controversial ideas. I would recommend this book to any project manager or architect working, or have worked on, a large system integrating other Legacy Systems.

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.

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.

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.

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.

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.