Custom Software vs. COTS Products

andy1307 writes "Nicholas Carr, best known for setting off a firestorm with his "IT Doesn't Matter" article published in the Harvard Business Review, has an op-ed in today's New York Times arguing against the use of custom-built software in favor of off-the-shelf products. He cites the example of Ford scrapping a custom built software solution for buying supplies. He says companies, frustrated by the failure of custom built software, have taken to modifying their business processes around the packaged software solution. The most unbelievable line in the op-ed: "When it comes to developing software today, innovation should be a last resort, not a first instinct.". Most of us know of failed projects using off-the-shelf products that need minor customization. Is the track record of custom built software really that bad?"

Comments

Yes it is that bad.

[Anonymous Coward]

For many years I made a decent living with projects picking up the pieces of 'customized software' (Usually the same thing, medium sized business went with untested contractors who can't deliver anything (it used to be a visualbasic or msaccess piece of crap but these days it's more likly to be a hacked opensource 'system' with zero documentation)...

I love opensource, but between it and toy languages like visual basic it's made an entire cottage industry of 'traveling-snake-oil-salesmen' computer hacks.

Depends...

[panurge]

In the ERP/MRP world, there need to be so many customisations and options that just deciding how to map the software onto existing business processes is a major challenge.

I have just advised a small company to use the small software company next door, not to build them a solution but to build them a model of two core business processes (currently on paper) in either Access or Filemaker (Yes, I know. But the ssc knows Access and Filemaker. OK?) The idea is that when they have defined the process and tested it, they can migrate to an MRP system and import the data they have created - because they will know which fields and reports they actually need, and they can more easily have a discussion about a small and flexible database than try and work their way through the options of an MRP system.

Having said that, the future may be off-the-shelf open source systems with customisation- provided someone solves the documentation problem.

The real problem

[einhverfr]

Is that most programmers suck. They can't design a good solution, look through software and understand how it fits together, document requirements, and actually, :gasp: design something that actually meets the requirements.

Most contractors can't run a business either.

I love opensource, but between it and toy languages like visual basic it's made an entire cottage industry of 'traveling-snake-oil-salesmen' computer hacks.

I don't dispute this. My company offers software customization services, and we have a few large contracts we are working on at the moment. We sell such services also with a support contract, and it is usually several meetings before we have the required understanding of the requirements to actually build the solution. In general, unless I understand how something is going to be used, I won't try to build it. Even then, any changes which need to be made over the first year of operation if they are due to it not meeting the original requirements are offered free of charge. This is our standard policy. We even pro-actively look for problems after it is deployed (in at least one case, we had to re-engineer part of a solution due to a misunderstanding about requirements!

We also try to sell training and workflow documentation along with the software customization. We do not, however, overly document our code because it is often easier to debug by reading code rather than comments (comments are used to tell the programmer *why* you did something, not *how* something works).

Also, we always contact the open source project maintainers before making the changes and offer to contribute back the additions to their source tree. This is because it makes it less costly for us to maintain if the project accepts our patches.

In general, we find that our customers are satisfied with our work. It costs less than COTS, and it fits their business more. We intend to be in business for years or decades to come, and expect our satisfaction levels to remain high.

COTS seldom works

[ColoradoRancher]

I've been in this game for nearly four decades, and seen the industry pendulum swing thru two complete cycles from all-custom to all-COTS. This was both in the private (Digital/Compaq/HP) and government (military & mil contractor) sectors of the IT industry. To be fair, my experiences are only in very large shops and companies. I don't know how this applies to small shops.

Everything I've experienced has taught me one very clear lesson: COTS does not work, for anything beyond a mail client or a suite of 'office' tools. Your internal business critical applications must be custom developed. And when custom developed, in-house development fares better than contracted custom devo.

I've noticed that COTS always seems to look better on paper, and starts off with a lower price tag. But even in the first week of deployment, that biz process you tried to bend to fit the software, just doesn't work when bent that way. So you start to loose business, or you have to modify the COTS software. Usually both. After a year, if you haven't gotten smarter and scrapped the COTS software entirely, and if your business unit is clever enought to stay afloat after that bad COTS decision, you find that you've had to customize it so much that it doesn't even look like the original. Oh, and surprise!, you've spent at least triple what it would have cost for an in-house development effort.

But wait, it gets worse. Eventually the COTS software just can't be customized any further, and must be scrapped. Your good developers... er, 'customizers'... see the ship is sinking. Most of them jump ship to the company that produced the COTS software, so they can do 'real coding'. Now you're doubly screwed.