Slashdot Mirror
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?"
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.
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).
Monstar L
The first thing you should think about before deciding to develop software rather than purchase it is: Is our organization a software company? If you aren't a software company, what makes you think you can successfully deploy a software project?
I developed this opinion over a number of years working for a Fortune 500 telecommunications provider. For political reasons, most of the developers had been promoted internally from other jobs. So now we had 30 people thrown at a project, only one of which REALLY loved the work. So there were a bunch of rather ordinary developers working for years on this "next generation" project.
In other cases I was supporting products developed by another division of the company. These products ran part of the order processing system, but were so buggy that the two of us supporting it literally couldn't take lunch at the same time because various components required constant maintenance.
I've come to the opinion that under all but the most extraordinary circumstances, a company should not work on developing custom applications in-house. They should either farm them out to a development company, or they should adjust their processes to work with existing Commercial Off The Shelf (COTS) applications. Concentrate on your core business and you're probably better off. If your core business is not software, you probably can't do a successful software project.
Sean
Unfortunately, at the moment few organizations are willing to pay enough for custom development (or system integration) to cover the actual costs, so to get any business at all, IT/SI/CS companies bid too low, and quality suffers (or they go out of business fast.)
If organizations were willing to spend what it actually costs to provide custom applications, then they wouldn't be so disappointed. I would include in "what it actually costs" things like people skilled in user interface design, and of course adequate project management, things that really matter to the customer.
Aside from that, we as IT professionals need to set these expectations much better. Customers really believe (because the sales guy blew so much sunshine up their asses) that it will all be perfect and on schedule. No one mentions (and few customers are perceptive enough to notice) that these projects are bid on before any of the requirements process has been performed, and the costings that go into the proposal are wildly inaccurate. But, no customer is going to go for a time and materials contract when some poor software company will offer fixed-price.
I am a big fan of iterative projects, with well understood features to be included in each release (that can be well costed out.) It's harder to go astray and the customer is getting incremental and obvious benefits from the money they are spending.
We are likely moving into another time period of preferring outsourcing/buying off-the-shelf software over insourcing. Then 5 years from now, some bean counter will yell "Eureka! Why are we paying these outside companies money to develop our software? We can save MILLIONS developing it ourselves!" And then the pendulum will swing once again toward insourcing.
This has been going on for decades and will continue to go on.
I'm a big tall mofo.
My company offers software customization services where appropriate, but we try to avoid reinventing the wheel where we can. Current such contracts involve adding features to SQL-Ledger's point of sale system, and modifying the same software for another customer to comply with Greek tax law reporting.
With open source software, you can lightly customize it to meet business requirements, and it is often less expensive than paying for COTS anyway. For example, another customer of ours (a restaurant) has a third party POS system with 5 terminals which cost them $30K. I could impliment a working system for them for maybe a third that and still meet their requirements (with required customizations).
I agree that building a program in-house from scratch should be a last resort, but, but hiring someone to add features to existing open source solutions is often less expensive than even commercial vertical solutions.
Also, with UNIX software, often the customization really just involves stringing a bunch of small useful utilities together in a useful way. Conclusion is that the article primarily applies to programs that run on Windows.
LedgerSMB: Open source Accounting/ERP
Carr is making a career out of his "iconoclastic" announcements. They're basically repackaged IT truisms, like "better to buy than build", which is the big kerfuffle here. His main asset is the PHB fear of discovery of their total ignorance of IT or business, beyond keeping their jobs and defending their budgets. A stable IT industry would welcome Carr's attacks, and use their buzz to get their non-IT bosses to accept some of the reasonable policies he sensationalizes. It's weird for Harvard to engage in this kind of hyperbolic fearmongering, but maybe that's just their idea of "innovation" over there.
--
make install -not war
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.
LedgerSMB: Open source Accounting/ERP
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.
Often the biggest issue when considering COTS vs custom software is existing processes.
.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.
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
> The first thing you should think about before deciding to develop software rather than purchase it
> is: Is our organization a software company? If you aren't a software company, what makes you think you
> can successfully deploy a software project?
Right, likewise - nobody should make their own food at home: there are plenty of restaurants out there that can make it for you. Think about it - you can save $20,000 for the cost of a kitchen on your next hour - and then spend an extra hour a day at work instead of making dinner.
Hell, why even wipe your own ass? Are you a programmer or an ass-wiper? You can probably find someone to wipe your ass for $20.
Of course, there are benefits to sometimes doing this stuff yourself:
- less likely to get screwed by a software integration company
- ability to exploit internal agile methods, rather than being stuck with more expensive waterfall methods due to contract language limitations.
- ability to build a solution that is exactly what you need, rather than forced to make do with a COTS app - that may be very different than what you need.
- ability to ensure that your hamburger wasn't dropped on the floor
- ability to ensure that your ass is wiped nicely.
Of course, if you are going to do your own software development - it is essential that you understand the risks associated with this. Get a few really senior, experienced, and talented people. Don't even bother writing your own solutions if you just want to hire idiots. Of course, there's nothing revolutionary here either - don't skimp on talent in engineering brake systems either...