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
Look, most COTS is crap, most homebuilt apps are crap. It's all a matter of finding the right tool to do the job. One isn't neccasarily better than the other. It would be foolish for a financial firm to design their own own in-house word processor for example. However they would almost certainly need their own in-house software to handle a lot of the back of the house. What I've often seen get ugly though is when people design their own custom software around COTS. If you do something like that and the COTS house says they won't support it you can be at their mercy and they don't have to do a damn thing. I'm on one project now using such a solution and the project has lost millions - and their contractually obligated to fill it out. The important thing one way or another is to set design limitation early and stick with them. The second important thing is to listen to the people who are going to use the software on a day to day basis when they say that something is a problem or would be useful. Failure to appease the people using the software can often carry more weight than success at appeasing management and their lofty goals.
Custom software projects fail constantly because the developers are morons or lazy scam-artists, the requirements aren't specific, and the company doesn't realize that a COTS solution exists. Millions of employees could be replaced with good custom software, saving businesses BILLIONS, but only if they build it smart, which doesn't often happen.
People who think they know everything really piss off those of us that actually do.
It is not often that I read a position paper in which I am nearly 100% in opposition to every idea expressed.
One of my professional pet peeves is people who feel it is better to identify a problem, then keep redefining the problem until it matches a prepackaged solution. The "if all you have is a hammer" syndrome at its worst.
Finkployd
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.
You can't say that that one solution will fit all scenarios. The reason most projects fail is not because of "custom" software or off the shelf products, its due to piss poor planning and incompetent project managers. There are many factors to consider such as size, scope, budget, resources, and requirements just to name a few. If project managers took the time to capture the real requirements and state meaningful objectives and expectations, then using either route would become clear. For example (very general), if the project calls for tracking the amount of training people have taken in an organization, then using almost any off the shelf Learning Management System would work as opposed to building a custom database to do that. Size of the organization also comes into play. A small business is not going to be able to afford an enterprise level LMS vs. a large company like Boeing or Ford. If the project would call for a system modeled around the companies specific policies and procedures, then custom software might be a more ideal solution. There might be particular legal or compliance rules that constantly change and an off the shelf product may not keep up to date with these quick enough.
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.
Even dedicated car mechanics rarely try to make their own parts.
Of , that said there are lots of patient talented folk who do.
Custom written software is more specific, often nicely tailored to the job and alot more difficult to support in a large integrated environment. Programmers don't hang around an old job site forever any more than construction crews do and wheather it's back to Bombay or San Fran getting it fixed 2 years down the line is alot easier when it comes with a dedicated external support team.
The future of software engineering is the same as that of any other industry - make hay while the sun shines and get used to it.
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
Large innovative projects are frequently doomed to fail. One major problem is that it is very difficult to staff a project properly. It takes very bright developers to build innovative things. It takes a lot of very bright developers to build very large innovative things. The odds of being able to collect the kind of talent needed are often very slim.
The top 5% developers are almost never found on the unemployment line, so you can't hire them from there. They are almost never working for body shops, so you can't find them there. Generally they are 1) comfortably employed somewhere else, and not interested in jumping, 2) working for a commercial software house and not interested in working for a company where they are "overhead" and not the center of the business, or 3) they are self employed and making much bigger bucks freelancing than they could be paid within a corporate job.
Most companies have a few of these highly qualified people. The best way to insure successful projects is to make sure that there are only as many innovative projects as can be staffed by your innovative people. A large business changing project is out of reach. But a several small to midsize projects can also transform the business, and can be executed by the staff of innovators already on hand.
There's a mantra which covers this perfectly: If you can solve 99% of the problem with 1% of the work, it's probably a good idea.
The large, expensive, and failed projects cited were run in what is a very typical manner outside of computing: A group of people sat down, decided exactly what they'd like to have, and then they hired another group of people to produce it.
The better approach is the 99% solution: Decide approximately what you'd like to have, then look around and see if there are any existing solutions, or parts of solutions, available which give you approximately what you want.
This is one way that computer software is very much different from "real world" products: If you're building a house, customizations aren't going to change the cost very much, since most of the cost goes into materials and fixed labor costs. With computer software, on the other hand, the materials and fixed costs are zero, and it is entirely possible for a 99% solution to exist at 1% of the cost.
Tarsnap: Online backups for the truly paranoid
I have seen major companies with bad IT hiring policies create custom software nightmares. A company I worked in created VB applications for all their needs, but to get a programmer, they hired internally based off a test. What they got where college grads, mostly liberal arts majors, who could fill out forms. This created a culture of tonnes of custom solutions for each process that needed addressed. No real it vision and a multi million pound clean up when they outsourced their it.
I have also seen in the same company money wasted on COTS software that didn't run on their base platform, and then effort gone into updating the platform to get the COTS software to work. This broke in house and other COTS software, and at the end of the day this piece of software was only pushed by the Finance department.
COTS is good for general business purposes.
Custom is good for your business specific processes.
If you are not an IT company don't do either.
Get an IT company to do this for you.
The outsourcing of IT, in the sense of the service model that is happening I believe will actually save some of the horrible waste I have seen in non IT companies hiring the wrong people, pushing the wrong projects and wasting focus on their core business.
I agree COTS will never cover all the computing needs of companies. But for bespoke solutions you have the service vendors there to give you that without any of the hassles of doing it completely in house.
I was thinking of the immortal words of Socrates, who said: "I drank what?" - Chris Knight (Val Kilmer)- Real Genius
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
I suspect the question is not whether the track record of customized-in-house software is bad, but what the track record of companies who do not have good software development skills/project management/methodologies is bad. (i.e. it's not the end product, it's the costs/delays/screwups in trying to get there.)
It sounds like there could be a third branch here between just buying COTS and trying to development something yourself -- work with a consulting company to develop a customized solution for/with you. That is, rent/acquire the necessary software development expertise/experience needed to get a properly done custom solution.
HR
Accounting
Inventory management
Payroll
etc.
My position on custom-written vs. COTS solutions is pretty much this: "If the problem's in our code, I can fix it. If it's in someone else's binaries, we're SOL.".
If the COTS software exactly fits the problem and has a solid record of not having bugs/problems, it's probably cheaper to use it than to write, debug and maintain your own. On the other hand, most often the COTS software doesn't exactly fit the problem at hand. This is especially true when the problem at hand involves differentiating your offering from everyone else's by doing things differently (hopefully better) than everyone else. In those cases custom-written software at least offers you the opportunity to decide whether it's worth it to make the tweaks. With COTS software it doesn't matter, because beyond the customization built-in you can't change it no matter how much it'd be worth it. Same things with bugs: with custom-written stuff you get to decide whether it's worth it to fix the bug, with COTS it doesn't matter whether it'd be worth it because you can't.
COTS is good for general business purposes.
Custom is good for your business specific processes.
If you are not an IT company don't do either. Get an IT company to do this for you.
The tricky part is communicating business requirements to the IT company. Since the IT company works in the IT industry instead of the customer's specific business, the IT company may or may not understand what the business really wants. If the business's contract negotiators aren't familiar with the requirements or the nuts-and-bolts of the business, they may not even know what is really desired, which makes miscommunication even more likely.
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 brewing coffee rather than purchase it is: Is our organization a coffee house? If you aren't a coffee house, what makes you think you can successfully brew coffee?
Seriously, all companies do work that they are not in the business of doing. As is usually the case, you have to determine the best course of action on a case-by-case basis.
> 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...
So now we had 30 people thrown at a project, only one of which REALLY loved the work.
I love reading stuff like thie. If you remember the age-old adage, "Garbage in, garbage out," the results shouldn't be any surprise. The company has, or hires inept management, who then has or hires inept employees, and somehow out of all this chaos expects some kind of magical force to take over and produce something great. It doesn't happen.
Before a company beings lamenting over a bad experience with custom software development, they sould really focus on how much they contributed to the problem. Before they even begin, they should ascertain how much they are willing to contribute to a positive outcome. There are so many ways a software project can be derailed, and I'd guess the inability to manage it effectively is one of the most prevalent.
Also, I can't help but wonder...how many of the people, OTHER than the one who loved his work, had four-year degrees?
In High Point, NC there are two companies that illustrate this issue.
Henreddon Furniture: Needed to improve their DB. Brought in Oracle and spent 18 months with an Oracle team fitting it to their business. Kept adding bells and whistles and went bankrupt without ever putting the Oracle solution in production. Bad planning by bad management? Absolutely. They never knew when to stop adding features and just do what they started. Wasted close to $5 million.
Culp: Still using programs written by in house development team. Some of these were originaly run on an S36 IBM and now run on an AS400. All software has been written, maintained and upgraded/updated in house. This is one of the very few textile companies based in NC to still show a profit consistantly in a very depressed industry (due to foriegn competition).
Why anyone should believe this: I had two instructors at the local Community College, one was on the Oracle team at Henreddon and went back to school for his PHD after the collapse, instead of moving halfway across country for the next job. The other is the head programmer at Culp and teaches at night. They know what they are talking about. One common theme: Spend the most time in planning, set the boundries, parameters, etc, then write code. Once codeing starts no changes should be allowed (by management) until the test stage.
Professional Politicians are not the solution, they ARE the problem.
Walmart is the killer app of inhouse IT. Any industry which uses computers can and should develop a competative advantage with custom software. Any one who uses COTS software in an area where some competitive advantage could be derrived is just giving that away.