Tim Bray’s post, Doing It Wrong is a great summary of the overall problem with large IT projects, contrasting the traditional practices of corporate IT with the more iterative, more realistic approaches used by Internet companies.
Having worked on dozens of projects over the years, this is a topic about which I have some thoughts.
Years ago it occurred to me that Amazon.com was a software company. That’s not news to anybody any more now that they’ve turned pieces of their infrastructure into cloud computing products that they lease out, but I realized it long before Amazon announced their Web services products, and even before they started outsourcing their online store and logistics to other retailers like Borders and Toys R Us. Early on, Amazon was thought of as a retailer, but their retail strategy was based on building the best software for running an online retailer. My guess is that Amazon.com knew from the beginning that they were in the software business, but a lot of companies that expend a large share of their resources building software don’t.
What I’ve also realized is that the best way to avoid failed software development projects is to avoid starting software development projects. Awhile back I worked with an organization that I won’t name. They were a very small shop that had a Web site, an online store, and an internal membership management application. All of them were custom and were maintained by an in house IT person who also performed every other IT task for this organization. The total head count at this organization was maybe five people, and yet they were maintaining complex applications built using ColdFusion and FileMaker. They had decided to rewrite these applications, combining them into a single application built using Ruby on Rails. The project was not successful.
While the scale was vastly different, the project was very similar to many massive IT projects. This organization’s entire business was run through this legacy software and the budget was very large by their standards. The rewrite was behind schedule, the requirements were not gathered well so the resulting application was not a good replacement for the (terrible) applications it replaced, and they were on the hook to keep Rails expertise in house or on retainer indefinitely because of this completely custom, highly specialized application they had built.
When I talked to them about fixing the new application, the question that popped into my mind was, “Do you guys even want to be in the software business?” Committing to this custom application meant that they would invest a sizable chunk of their resources into software development forever, and they lacked the expertise to manage such a project. The right solution for them really was to dump their custom application and use whatever existing software they could afford that would allow them to move forward, even if it was quite different from what they had before.
I think that’s true for a lot of organizations. The question people need to be asking is how little custom software can they get away with having. The ideal number is zero. If you’re working at one of those web design that rolls a new content management system for every customer, you’re doing your customers a disservice. Honestly, if you’re selling them your own proprietary CMS you’re probably doing them a disservice.
Software developers like to build things. And most developers are confident that they can provide something that perfectly solves whatever problem they’re confronted with as long as they can write it from scratch. Developers are horrible at estimating the long term costs of building applications yourself. And they have an incentive to be bad at it, because if they were good at it, nobody would let them loose to write custom software.
The first question everyone should ask when thinking about building custom software is, does building this give me a tangible strategic advantage over the competition? Specifically, does it provide enough of an advantage to make up for the amount you’ll spend on initial development and on maintenance and improvements going forward. Account for the fact that packaged software will likely be improving over time as well, so your custom solution may be great today, but the feature set in the packaged solution may blow away what you have two years down the road.
The second question is, how small can you start? The larger the project, the more likely it is to fail. And by small, I mean relative to the capabilities of your organization. If you have one in house developer who has other responsibilities as well, pretty much any project is large. You want to start with something you can release right away. Starting small is easier when you’re doing something totally new and difficult when you’re trying to replace something that already exists, but that’s really a warning against replacing things. Replacements for existing applications are the projects that are most likely to fail.