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

"innovation"

[zarr]

"When it comes to developing software today, innovation should be a last resort, not a first instinct.".

Maybe this is what the author really meant to say: When it comes to developing software today, reinventing the wheel should be a last resort, not a first instinct.

It's all competitive advantage

[antifoidulus]

Any freshman course in Engineering economics can tell you that 99% of the time it's better to buy than to make. You only make what is core to your business. Ford's methods of buying parts/inventory tracking wasn't too unique, so there would have been no reason to make the software unique.
However, if all you do is buy, you give yourself no competive advantage over the other guy who has access to the same resources as you. Ford probably has a lot of custom software in their factories because that is what really differentiates themselves from the rest of the pack(whether the distinction in this case is good or bad is left as an exercise to the reader).

Re:It's all competitive advantage

[freemacmini]

Even if you buy you have to write tons of custom software. Applications like SAP, Seibel etc are not like a word processor where you just install and launch, they are more like application frameworks where you "script" using some proprietary language to make the application do what you want. Most corporations who have deployed these types of applications have a team of developers who do nothing but code in it all day long. Check monster.com for SAP or Seibel jobs and see. Of course these "applications" give you a ton of functionality and maybe it's better to start with that then to roll your own but I think it's a tough call. They cost millions and take months if not years to implement. Finally there is no shortage of companies which tried to implement a monolithic system and gave up after spending tens of millions of dollars. Spectacular failures are not uncommon.

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.

COTS vs Custom

[Liquidrage]

Often the biggest issue when considering COTS vs custom software is existing processes.

Typically, when we evaluate COTS products 9 out of 10 are missing *something*. Not to mention 8 out of 10 cost more then it would take to write from scratch because 50% of the COTS offering wouldn't be used so doesn't have to be developed when writing custom.

The existing processes is really the key though. Too often the person who needs the software has the money to get it (either COTS or custom) but not the authority nor the desire to change an existing process to fit a COTS offering. This is a more of a problem with bigger organizations. And it hurts the chances of using a COTS product. But let's not pretend there are not some cases where changing the process is not sensible nor possible.

If your mission is housing inmates, do you think generic COTS inventory software is really going to suffice? No. The only commercial offerings are custom software written elsewhere that the original developers will sell you. Basically they'll gut the code that doesn't fit and shoe-horn in some new code. Thanks, but I'll pass on that.

Also, another area where COTS products typically struggles is interfacing with existing software and data. Commercial app that tracks training? Easy to find. One that will leverage existing data such as an HR database? Well you just lost 90% of your potential COTS prodcuts and those other 10% are going to be just as expensive and take just as long to develop most likely.

And lets not forget that in most places, COTS products are the majority of software. We don't write word processing application, we use MS Word. We don't write a web browser from scratch, we use an existing one. Etc.. But when it comes down to supporting an existing process, use it where it makes sense.

Now, as to custom software sucking...
A lot of it sucked. I believe the best thing that ever happened to custom software was the trend of making it web-enabled. Whether it was PowerBuilder, C++, VB, FoxPro, etc..., too much custom software built in the 90's sucked because of their interfaces. I've seen literally 100's of custom client server software written in the 90's and about 95% of them suck and allmost no two act or look alike. Of course this can be overcome with strong development methodologies. But in the real world not every place nor project is wrapped under a strong methodolgy. And very few projects I've done for custom software and anything even close to a working UI team. Not to mention that in the changing software world technology changes fast and even the best and most disciplined development teams can have interfaces that look nothing alike even if they were developed just two years apart.

To me the greatest strength of web-apps isn't ease of deployment. It's that is forces developers to write simple interfaces. Web apps written by the same software teams generlly do look alike. And even where they don't they at least act alike. MS tried came to us trying to sell us on the ability to use .NET to write regular windows forms apps that are run in the browser. Why I asked? So we can go back to the days of complicated UI's that confuse the user and make maintanence when you were the original developer nearly impossible? No thank you. I understand there will always be applications that have requirements that are not suited for the web. But they are, I will use that. I will keep my interfaces as simple and clean as possible and users that are not 1st and foremost computer people will continue to be able to operate them without a steep learning curve.