The Codist

Disaster #3: The Sisyphus Project

Description

Sisyphus was an ancient greek mythical character who was eternally condemned to roll a stone up a great hill, only to have it always roll back down so he had to start over. In this type of disaster the project can only be worked on with great effort, long hours, difficult work and usually massive stress and pressure from management. Once a version is delivered it begins again. These type of projects usually burn out developers leading to many new additions not familiar with the beast, so it actually gets more difficult over time.

Example

I've been fortunate to have never experienced this type of project, so I don't have any concrete examples. I do know that this is not an uncommon situation in many companies and there are usually two underlying causes: a lack of experienced technology leadership and management ignorant of the realities of software development.

Software development today is actually much more difficult than it was when I started 25 years ago; the number of technologies required to build and maintain a modern application is almost too much for anyone to comprehend, must less architect, design, test and ensure interoperability with other systems. Simply choosing a set of tools and technologies to use is a challenge since no one can have experience in everything (despite what you see in job ads). If the technology leaders (architects, project managers, project leads) have only limited experience with or even refuse to acknowledge better alternative choices then the base of an application may suffer for the rest of its lifetime (and the programmers with it). Discerning potential problems in technology choices before they become a real problem requires a willingness and time to experiment or prototype before embarking on a big project. Jumping into a large project with unknown technology is begging for a disaster.

Top-level management often has no real clue on how technology choices may affect the cost, time and performance of a large project, preferring to listen to sales pitches from vendors instead of their own technology leaders. Then when a project starts to have difficulty they may assume their team is at fault, as the vendor assured them "it was easy". Now they pressure the team to deliver and the ball starts rolling uphill.

One company I worked for embarked on a new portal strategy for its customer and sales force facing sites without any real idea why, other than a desire to join the crowd. Porting the customer site (already written in a mishmash of technologies and styles) to the portal took much longer than anyone predicted and created am even worse mashup of code which was difficult for anyone to properly test or sometimes simply get to run. The sales force application portal was always threatened but no one ever wanted to start it. See below.

Disaster #4: The Ten-Foot-Pole

Description

Some projects are so important and far-reaching, they simply cannot be started at the present time due to manpower shortages, business reasons, cost, or a surplus of cosmic ray particles. Actually any reason is sufficient to avoid having to do this project even though not doing the project may cause even greater problems. In most businesses it’s far easier to justify painful existing processes or systems than to step forward and tackle a replacement. Due to its enormous importance the project never goes away but remains just out of reach.

Example

The best example of this was a smaller local defense contractor which asked the consulting firm I worked for at the time to come in and see what we could do for them. Some of their managers discussed with us their problems in development for the web (this was late 90's) since no one had any experience with it. They knew many of their systems and applications were too inflexible and hard to use and wanted some (easy) was to fix them.

This all seemed reasonable to us in the early heady days of the web until we asked about their database systems. They mentioned they were still using databases designed in the early seventies and had coupled the applications directly to them. When asked why they hadn't updated the database system in nearly 25 years they replied that with a project-based accounting system, someone would have to pay for it out of their project budget, and then be held responsible for any problems it would cause (likely to be huge since it touched everything the company did). There was no management responsible for the company's entire technology environment so no one had enough authority to even look at the problem.

Given the tremendous coupling of the company's applications to the neolithic database system we found nothing we could do to help them and nothing was ever done. One can argue that "if it isn't broken, don't fix it" but often the problem is not that the current system is unusable, it's that it's inflexible and potentially unmaintainable. In this situation the company was unable to improve their productivity as the old applications were difficult to use, brittle, and especially hard to modify as business needs changed. So changing technologies was painful, but keeping the old technology was equally painful but at least familiar. The company is still in business but losing money (a rarity for an longtime defense contractor).

Solutions

Both of these project disasters are complex problems usually with the decision-makers in an organization. Unless you are one of them it's difficult to fix the problems from below. If you are one of them the best solutions are:

• Educate Yourself - read unbiased reports, news and even technology sites to gain an understand of what people are doing, and how effective the solutions are
• Never Believe Vendors - don't let vendors convince you of anything unless you can get independent verification. A consulting firm salesman I once worked with told me "His job was to lie to customers, and mine was to make him look good".
• Hire Broadly Experienced Technology Leaders - find people who are willing to learn and use anything, have worked with many technologies, preferrably hands-on, and especially are willing to speak their mind.