My software project rant

A colleague of mine sent me this link regarding an anti-pattern that I am, unfortunately, extremely familiar with. This is an all too familiar scenario for me and indeed for anyone who has spent a significant amount of time working in the software consulting field.

It is named, very appropriately ‘The Lava Flow’ anti-pattern and it is basically a description of what happens when the ‘get something out there fast – we’ll fix it later’ mentality take over a project. The authors detail a scenario where research or demonstration projects

The scene is played out this way in the consulting field…

A software consulting company becomes aware of a software project opportunity. The business development team (usually a group of marketing professionals, with little or no technical expertise) rush in and try to close the deal with the client (usually a group of high level management types with even less of a clue). They are asked by the client to present their technical expertise, so they grab the first poor boob they can find (usually a new hire) and ask him to put together a proposal with as many acronyms and buzzwords that they can throw in. The lone developer is asked to put together ‘prototypes’ and ‘technology demonstrators’. Then to sweeten the pot and close the deal, they blindly agree to the ridiculous expectations that the client sets.

Once the deal is closed the business development team conveniently disappears leaving the ‘minor’ delivery details to the developers. The developers come in to find that they have to deliver a complex project with requirements in the form of some power-point slides and scribbling on paper napkins. Oh, and they have to deliver it tomorrow…

There is usually no one from the clients’ side that has a clear idea of what is required so requirements are made up (we don’t have time for design sessions, and certainly no time for usability studies) and the project lurches on. The ‘prototype’ created by the business development team is proffered as a pilot. The delivery team is to use it as the base for development of the enterprise application.

In a reaction to the complaints from the developers regarding the lack of time, a bunch of bodies are added to the team (to increase the rate of development). With no clear architecture or design and certainly no time to sit together and come up with one everyone sits down and develops their modules the way they please. A few cursory tests would be done to ensure the code compiles and builds and works like they think it should and the project is delivered to the client.

The client meanwhile has no idea as to what the project is supposed to do. They have changed directions during the development many times and no one has kept track. Since there is no clear idea of what is to be delivered, they have no idea how to test it. Besides the pressure to get the application ‘out there’ is high. Their competition is supposed to bring something similar out at the same time and they cannot afford to lose the ‘first mover’ advantage. The project is deployed.

The developers working on this project are now re-deployed to other high-pressure projects (usually to repeat the same story all over again). However, the client comes back with more demands, enhancements, changes and defects. Users are not happy with the user experience and the application is not capturing the data that the client really needs. The numbers of users using the application have increased and it is unable to scale. The client invokes the contract and pushes the blame on the consulting company. The application needs to be fixed and fixed fast.

However the original teams of developers are no longer available. The new team that has come in has no idea, about the application. The little documentation that exists is not relevant as it does not reflect the current design of the application in any way. The application itself has no consistent architecture and design. The team has no way re-factoring or improving the application as nobody has a complete picture of the application. Nobody wants to change anything for fear of breaking something else. So hacks are created. Additional code is added that modifies the output of existing code. The original code becomes hardened and un-modifiable like lava.