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.

Chuck Allison’s interesting article “Software: Use At Your Own Risk”, (Better Software Magazine, July/August 2008, p. 9) discusses the risk inherent in software licenses compared to other warranties, reasons for the lack of quality in software and lists a sample of the code of ethics of the Association of Computer Machinery.Here are some reasons why I believe that the Government will not take effective measures to enforce more liability on software vendors in the short or long term (within the next 10 years).1. Consumers are instant gratification junkies. Consumers want things ‘now’ and are only mildly disappointed when they have small failings, so they do not officially complain so much as in other industries. We only have to look at the lines outside Apple Stores for the new iPhone to realize this. Many people were not even concerned that some phones had activation issues, as they understood that Apple would eventually fix this.2. No physical boundaries. License issues will differ in different countries and trying to enforce this will be an administrative and legal nightmare. Also, software can be downloaded from the Internet from anywhere. Even the attempted Chinese firewall was worked around within a day3. It is understood that software is never defect free. Maybe this is not the right attitude, however it is one we have ingrained into ourselves over the last 20 years as both users and developers. Microsoft’s famous Blue Screen of Death was frustrating for developers, but after a quick reboot, work continued – it was accepted (I say “accepted” as it was the most common OS used and there was no mass exodus to UNIX, or later Linux). Would the same attitude apply if your car broke down several times on your way to work?4. Software organizations do not learn. Many articles quote from references such as Brook’s ‘Mythical Man Month’. This book was written 30 years ago and many of the failings in Software Development back then still exist today. For example adding people to late running projects only makes them later.5. Perceived insignificant importance. We know the cost of failed software is in the billions, but other things in the public eye have happened to constantly keep this from being a primary concern. For example, The Gulf War, 9/11, Presidential elections, rising fuel prices and the current Fannie & Freddie crisis. Although software is involved everywhere the quality is not considered a public priority.One of the ethics Allison lists is “Contribute to society and human well-being”. Unfortunately, for Governments to pass legislation of the sort suggested by Allison, a monumental catastrophe will have to happen. We saw something along these lines with the introduction of Sarbanes-Oxley compliance following the Enron scandal. However, even if a plane were to crash due to software error, it is unlikely that even loss of life would be enough for the Government to pursue measures. In my opinion, the outcome would be that the airline and the manufacturer would have lawsuits filed against them, while the FAA and software producer would, at best, experience some bad press.

Two of our recent blogs; The Misnomer of Best Practices and The Dreyfus Model are tied together nicely in this episode of Enerjy.tv by way of a conversation I had with Dan North of Thoughtworks.

Dan regularly speaks and blogs about these topics and gives his views on where so called Best Practices should be in an organization and how they are used depending on your position on the Dreyfus Model. Dan gives examples of how developers use Best Practices when starting a new skill or position within a company and how these practices and rules diminish in importance and become a hindrance once skills levels rise towards the Expert level.

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.