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.
January 6, 2010 at 6:47 pm
Fascinating post. Thanks for sharing it!
January 7, 2010 at 2:51 am
The thing I always see missing in those discussions, though, is, how precise a fit are off-the-shelf packages? Just as common as failed in-house projects are situations where management considers home-brew software a no-no, and buys “off the shelf” solutions that then have to be customised very extensively, and often cannot even easily be made to fit essential (or nearly so) requirements. In such cases, the cost and fit of in-house development would often compare highly favourably if only management weren’t scaredy-cats.
There is no free lunch. To make off-the-shelf software work, a big part of the picture is willingness to bend your organisation and your requirements where you would have to bend the software too much. Something has to give, after all – otherwise, failure ensues.
January 7, 2010 at 10:23 am
I think that’s exactly right — you either have to shape the software to fit your business or fit your business to shape the software. I just think that the ease of shaping the software is overrated and the ease of shaping the business is underrated.
January 7, 2010 at 10:25 am
Yes to this. When I was at a small WebDev shop last year, I kept suggesting WordPress for the small sites that wanted (but did not need) a CMS.
It’s also why I’m switching my current company from a large, custom-built CMS, to Drupal.
January 7, 2010 at 1:08 pm
Good advice, but I agree with Aristotle that off-the-shelf software can have similar problems. Anything more than a trivially complex problem requires customization. We have several times pushed back against buying off-the-shelf solutions because although the product had many features (many which we did not need), the cost of buying AND customizing it to meet our needs would have been more than building our own solution from scratch. The long term costs were problematic as well – because the products all had their own “way to do things”, we would have needed an internal person to learn the new model to apply changes/fixes or hire consultants from the other company to deal with them.