Buzzwords Kill. How terms corrupt decision making in software projects.

I recently viewed two major software development projects fail. Fortunately, I was not directly involved with either of them. Over frequent conversations with the software developers, managers, and architects involved, I see a common thread: Buzzwords misused to strengthen an agenda or for empire building.

The two projects failed to the mis-application of two technical terms: J2EE and RUP. I'll start with the first, J2EE.

A multi-year project for a large piece of enterprise software started with a wide scope and few technical rules imposed by the client. The main technical directive issued by client was: be J2EE compliant. Early in the process, Software Architects with little expertise in Java/J2EE defined a core set of architectural goals. Ignoring the "common wisdom" gained by 1000s of projects and companies, that EJB is more often inappropriate than not, they defined the core architecture as EJB on J2EE. They declared that everything in the system should be represented by EJBs, and that all state information and message passing be handled by EJBs.

The result was easy to predict, although I can't fully credit the failure with the abuse of EJBs. Change requests took days or weeks for even the most simple of changes. Large parts of the system were never even started as the environment was soo cumbersome to developers. While I can't disclose the project's current state, you can probably guess...

Before moving on to RUP, let me say that the failure here was not primarily the EJB specification. The real failure was that "J2EE compliance" was interpreted to mean "everything must be an EJB". While not referring to "empire building", this certainly does refer to "agenda setting" and an abuse of power by the software architects. Had they cared to visit the few groups actually doing Java and J2EE development, they would have quickly understood that EJB is simply one part of a greater framework for software development in Java.

Now for RUP. Having just taken a course in software development lifecycles (SDLCs), I understand that RUP is a framework for modelling SDLCs. You can tailor RUP to be very much like Agile, or you can make an ancient Waterfall SDLC, or anything else for that matter. The project I mention here actually refers to several failing projects.

Perhaps for "empire building" or perhaps just for lack of understanding, the "process staff" decided to use absolutely everything they could find in the RUP SDLC. Even where it didn't make sense. Where they could have multiple iterations, they had many. What they didn't ever do was read up on how projects can succeed or fail. Here are some key factors from the CHAOS report by the Standish Group, describing the most common reasons software projects fail:

• Lack of user input.
• Lack of complete requirements.
• Changing requirements.

Now, what have we as a community of Software Engineers learned over the past several decades? That the waterfall doesn't work except for a very few, extremely expensive, no way to patch applications such as Space Vehicle Software, Bank Software, etc. For most other applications where patching is possible and even likely, a more iterative/evolutionary/Agile approach is called for. Well, at work they choose extremely long RUP iterations (average of 6-12 months) and phases lasting for 1-2 years. Many of these projects are already several years old without a single line of code written or customer/end-user feedback. Most major business leaders lost all confidence that these projects could ever succeed, and most assume they will be discarded.

In summary: Be careful when using buzzwords, and do not make decisions based on buzzwords and acronyms alone. This may seem like trivial advice, but perhaps it will save you or someone else a failed or delayed project.