Why is that? I doubt that anyone starts a project thinking, “this project will probably waste a few hundred thousand of dollars, sidetrack the department for a year, hurt our reputation, and cause countless sleepless nights, but let’s just jump in and hope for the best.” I’m sure that every project begins with competent professionals who honestly believe that the project is needed and will be successful.
I believe the primary cause of project failure is custom code. Think about it this way, How many deployments of Microsoft Office have gone 300% over budget and taken an extra year to deploy? None. Because it ‘s all mainline production code. There’s no custom code in Office. (note that Access, Excel, and Word can be used to create custom applications, but I’m writing about the installation of Office itself, not using Office as a development platform.)
Customizing an existing application with custom code is risky for several reasons,
- The programmers writing the custom code are typically not the same person or group that made the initial promises concerning the features of the customization. A common complaint is that what sounded very good when talking with the sales engineer sounds difficult when talking with the implementing programmer.
- Custom code is rarely developed by the same programmers who wrote the mainline code. Reading existing code and fully understanding all the consequences of adding new code or modifying the existing code is very difficult. In the PluralSight course on Technical Debt, Mark Heath states that reading and understanding existing code is one of the most difficult tasks of a programmer. In fact, an entire discipline of software development is devoted to best practices of refactoring and extending code.
- Custom code often duplicates portions of existing code. When writing new code the programmer is often cautious of modifying any existing working code, so code is copy-pasted, which duplicates code and further compounds the problem of testing and debugging.
- Custom code is rarely fully tested because test cases and test data for the custom code are seldom available and the resources are not allotted to formalized testing. Even when the custom code is informally tested, the mainline code is almost never tested with a full regression test to ensure that the custom code does not break some aspect of the mainline code.
- Customization means that future updates to the main line of code often breaks the custom code, or the custom code breaks the future updates to the mainline of code.
- Programmers are good at estimating how complex a task might be, but are notoriously inaccurate at estimating the duration of a task.
- Because the intention of custom code is to be deployed for a single client, the seriousness of the architecture and the quality of the code is often less than what’s invested into the product’s mainline code, which is planned and developed with the intention of thousands of deployments.
Are these seven reasons absolutes? No, of course not. One in four customization project succeed. And, professionals use specific techniques designed to mitigate these risks. But, these are the reasons why 75% of all large scale ministry software projects fail.
My friend, Pete Holzmann, pointed out another reason why he sees custom software projects fail. If the project takes more than a year, there’s a good chance of some personnel turn over that affects the project. A change of programmers, key stakeholders, project champion, or leadership could be enough of a change to alter the project requirements or derail the project altogether.
A typical large custom software project takes 18-24 month or longer. How much will the ministry change in that length of time? Will the project, once complete, if it’s completed on-time, meet the needs of the changing ministry?
For all these reasons, commissioning custom code to alter an existing product is risky at best. IT leadership knows this, so why would a ministry ever agree to customized software? Usually, it’s because they don’t see any other option.
The solution? configurable software.
- Paul Nielsen
Founder, Ministry Weaver, inc
Microsoft SQL Server MVP
author, SQL Server 2008 Bible