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?"
But the places I have worked, there are thousands, if not more, of tiny business processes that would be a waste of time for a commercial company to develop a "solution" for.
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.
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.
Panurge has posted for the last time. Thanks for the positive moderations.
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
...When a company does need (not want, but need) to change, they will find themselves trapped by the product that was going to save them.
The most common problem I see is that when they do try to change, they will attempted work around their COTS. Not by designing a completely new solution but by slapping something together.
The Company (small, less then 50 people) I've started working for is paying the price for doing just that. They tried to build a MS Access Database App to work with a software product that is now critiacal to there business.
It work at first but grew out of control and is full of proor design and wierd bug fixes that realy didn't fix the bugs. The two guys who started it about 3 years ago are no longer with the company. (One quit in fustration, the other fired due to inter office politics)
Its gotten to the point that with the system breaking at various point, customers getting pissed and the four new IT guys (myself included) pulling all-nighters, that the company's CEO has gotten the messege and started throughing money into IT.
I'm optimistic that things will get better in 6 months to a year but, had my company been willing to inovate, instead of working around a pre-made software product, they'd be further ahead than they are now.
I think I think, therefore I think I am.
LEAVE IT ALONE
Too many times organizations I've been in buy a piece of COTS (using the %80 metric even) and then start tweaking and nudging and twisting - until they are hostages to the company who sold them the COTS and made the changes for them.
Essentially having built their own customized solution out of an expensive piece of COTS.
Exactly correct. Peachtree Accounting is crap, it's COTS, and many, many in-house projects are crap, but there are benefits to both. Products like Oracle exist because it is cheaper to buy database software than to create it and maintain it (the code, not the database). Look at your average corporate pizza shop though (Papa John's, Domino's, Pizza Hut, etc.), they all have custom, in-house developed software, but it works, and they each have their own ways of doing things that reflect how their particular company operates (and they are quite different).
If your business does something other than simple transcription, there are almost always benefits to custom software. The only question is whether those benefits outweigh the costs. If you need constant changes to software so your business can adapt to rapid changes in your sector, you probably need in-house development. Paying a dev firm will get very expensive if you need to change something every 3-6 months, and having someone who knows your system working full-time for you has a lot of value as well. Try calling Peachtree, they have one of the most popular accounting packages out there, but call customer support and tell them you're having problems running it with files shared on a network. If it's not running on a single machine, with Admin priviledges, it won't work. They'll tell you that, but only after you buy it and call them 20 times about the same thing breaking.
You could take a dump in a box, shrink-wrap it, and sell it to somebody. Just because it's shrink-wrapped, doesn't mean people will be happy with what's inside.
--That's the point of being root, you can do anything you want, even if it's stupid.
What we do where I work, and it works well, is to use off-the-shelf products wherever possible. We do make sure that the stuff we get has some level of openness, so that we can build custom stuff around it and customize to fit what we do. An ERP, for instance, can't account for all your business processes. Chances are your company has something unique about it that can't be accounted for with off-the-shelf software. Hopefully you can account for that by building custom stuff.
The perfect sig is a lot like silence, only louder
I've worked for Ford, I've seen many project scrapped. It's incompetence in Ford's IT management that's the problem.
DCAS, FocalPt, hundreds of millions wasted on bullshitters, many many incompetently run projects have never returned their money.
I've also done many very successful custom IT projects.
So it's not right to judge project's based on Ford's incompetence.
Sure, using COTS makes sense if it does what you need. No one disagrees.
The difficulty is that answers to big, complex problems usually aren't found in a box. Before someone can give you a solution, they must have first envisioned your problem.
A better strategy is to have an infrastructure upon which various solutions can be developed independently and in parallel. Take the Internet, for example: a common infrastructure with, at first, only a few solutions, but now, with millions.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
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.
I've seen both custom and COTS solutions succeed, and I've seen them both fail miserably.
As a number of folks have pointed out, the PM/planning/Requirements gathering has a huge amount to do with the eventual success. As does the willingness of the users to actually adopt the system.
You'd hope the if you involve all of the stakeholders at the right point they will buy into the final solution, but in reality, the corporate politics can kill a technically exellent solution more effectivly than a politically supported but technically weak solution.
If people have some degree of buy-in to a solution, they'll overlook a lot of v1.0 warts. If they hate it for political reasons, they won't rest until those responsible for it have been sack, the people who sacked them sacked, and so on...
unfortunatly, this usually leaves the user community (e.g., the company) in the same or worse mess than they started.
I am actually in the process of deploying SAP Business One at the place I am working. You are 100% correct in that the core will just get you by in most situations, but that you can tweak these products to fit your (almost) every need. My ONLY complaint about SAP business one is the lack of the ability to do conditional printing. Is it so much to ask that if I create an order, it prints at one spot, and if I create an invoice it prints at another? The software we're moving from(silversystem or something like that, runs on PICK OS) had this feature, and my company had been on that since 1992ish.
p
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
It's the management that is the problem.
It doesn't completely matter whether the software is developed in-house or customized commercial software - what matters is does the software do the job, can be it be further modified without excessive expense as the business changes, can it be cost-justified against business revenue or savings resulting from its implementation - and a dozen other standard IT 101 lessons that most managers don't seem to have learned in college...
This guy is a self-promoter whose method is very common: claim that any one solution is totally wrong and the opposite solution rigidly applied is the only possible way to solve the given problem.
In other words, he takes his cue from George Bush...
Right now at City College in San Francisco, we run a standard university admin package which is a pain in the butt. On the credit side, almost no customization (other than that allowed by the package's internals) has been done. On the non-credit side, a fair amount of customization has been done. The man who did most of that customization is looking to retire and when he does, support for those customizations will go out the window. Without those customizations, however, the package would not be nearly as useful to the non-credit division.
OTOH, the library uses an ILS (Integrated Library System) package which is out of date, and has signed a contract with another ILS provider to implement a new one. Part of the contract is that ILS provider must provide integrated access to the college admin system (for example, use the patron ID to verify that the patron is a registered student). This has been tried before in other areas without success. Most companies don't like to have to go into their "standard" package and modify it to allow integration with someone else's package because it reduces their profit on the sale to do customization. So the salesman sells the package by promising integration in the contract, then the company backs out or waters the integration requirement down in order to save their profit on the sale.
In this respect, OSS is much better since the money you end up spending for customization - and you WILL spend that money one way or the other - takes less bite out of your budget than it would if you had to pay for the software first. Better to get the source code and pay some consultant (and in OSS especially, this "consultant" may well be the original developer) to modify it than either develop the entire thing in house or pay a third party consultant for modifications on TOP of the cost of commercial software.
Somehow, management doesn't seem to grasp the simple dollars and cents logic of this.
Big surprise.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
The reality, however, was that the business solutions we needed to solve were actually quite mundane and could easily be solved with less exciting techniques and platforms.
I work as a software engineer currently, designing and building a product for in-house use. However, there's a commercial product which could probably be used to do the same thing; it includes its own programming language which is somewhat similar to C, and designed to hook into our simulator software the way my in-house product does.
However, I've been extremely vocal about not using this other product, for several reasons. For management, the reasons I give are 1) that it's expensive, and 2) it'll have poorer performance than our custom solution, and 3) it requires specialized knowledge, whereas our in-house product is written in C/C++ which it's a lot easier to find people with expertise in.
But my big reason for not wanting to get involved with that commercial product? I don't want to pigeonhole my career into becoming an expert in some special proprietary product. By doing work in C/C++/Perl/Verilog, it'll be much easier to find another job if the need arises. If I become an expert in this commercial product and its proprietary language, my career is basically over. No thanks.
In this age of short stints at different companies, and HR people only looking at buzzwords on your resume, you're better off with lots of experience in popular, non-proprietary tools and languages which can be applied at many places, rather than a narrow expertise in one thing which may lose popularity, or worse in my case, just isn't something I want to be doing for the next 20 years.
Think of the great companies that are known for their outstanding support and customer service (which DOES differentiate and tends keep customers coming back). The secret to their success is rarely a secret formula or a training process. The "secret" is generally plenty of good management, good front-line workers, hard work, and a certain attention to detail. The method may not be proprietary, but proper execution (read: good and consistent service) is a rare thing in this world. Software can be a very helpful, even necessary, tool for improvement and it can help further differentiate even if the competition is theoretically able to copy it.