Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software Programming IT Technology

Custom Software vs. COTS Products 325

Posted by timothy from the need-a-dozen-in-albuquerque-by-friday dept.
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?"
This discussion has been archived. No new comments can be posted.

Custom Software vs. COTS Products More

Custom Software vs. COTS Products

Comments Filter:

  • "innovation" (Score:5, Insightful)

    by zarr ( 724629 ) on Saturday January 22, 2005 @03:07PM (#11443126)
    "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.

    • Re:"innovation" (Score:3, Insightful)

      by beaststwo ( 806402 )
      A really good point. I started writing software again several years ago when I realized two problems with COTS software for specialized problems:

      1. The capabilites may not be available on the market at any price.
      2. The capabilites may have such limited mass market appeal that they exist only in the outskirts of COTS packages, and are badly done and/or not supported well (remember Willie Sutton's answer to why he robbed banks?).

      It's important to realize the difference between "unique, difficult to fil

    • Re:"innovation" (Score:3, Insightful)

      by slantyyz ( 196624 )
      In the software development companies that I've worked in, the problem was that developers just wanted to play with the newest technologies so that they wouldn't get bored. 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.

      While I understand the desire (and need)to play with the latest bleeding edge platforms, techniques and technologies, there is a time and place for that.

      More often t

      • Re:"innovation" (Score:3, Interesting)

        by Grishnakh ( 216268 )
        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.

        • Re:"innovation" (Score:3, Insightful)

          by slantyyz ( 196624 )
          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.

          Without knowing details about your particular situation (your argument could very well be justified), the boilerplate management arguments against your position are:
          1. What are the costs of the app versus the fully realized burn of in-
    • > reinventing the wheel should be a last resort, not a first instinct.

      yeah, but this guy doesn't know enough about IT to understand that most commercial IT wheels come attached to a commercial IT locomotive engine.

      For example, when you only wanted a utility to copy data between databases, and you end up stuck with a $250,000 commercial ETL solution - you are hosed:
      - It's going to cost you $75,000 in annual licensing fees
      - will cost more to add to more servers
      - will probably require training
      - configurat

    • Re:"innovation" (Score:3, Insightful)

      by vsprintf ( 579676 )

      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.

      What the author is saying is you shouldn't build a house because there is a company that makes double-wide trailers, and one size fits all. It's more nonsense from a guy known for spouting nonsense, and that's the best reason to ignore it.

  • It's all competitive advantage (Score:5, Insightful)

    by antifoidulus ( 807088 ) on Saturday January 22, 2005 @03:09PM (#11443139) Homepage Journal
    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).
    • if i had 100 mod points i would give you them all :)

    • Re:It's all competitive advantage (Score:5, Insightful)

      by freemacmini ( 852263 ) on Saturday January 22, 2005 @03:28PM (#11443296)
      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.
      • 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
      • I think the growing problem with "off the shelf" software is inflexibility. Often you end up with software systems which do not do what you really need them to and you can end up spending a considerable ammount of resources trying to get what you need out of it. The main problem with this is that smaller software companies that address these needs are getting harder and harder to find, while larger software companies are only interested in big generic systems they can market to everyone.

        If you can find o
    • It's about Risk. Google doesn't use COTS but you can bet they use lots of COTS bits from RAM to HDs, but when they really need the advantage of custom, they manage the risk and hire really good people like Rob Pike (just to mention 1 of many!).
    • > Any freshman course in Engineering economics can tell you that 99% of the time it's better to buy than to make

      And any graduate course in engineering economics can tell you that there is no choice of buy vs make for large enterprise apps: the choice is buy & customize vs make.

      And given that most enterprise apps have been built as monolithic software rather than truly distributed components - customization is expensive, risky, time-consuming, and difficult to maintain.

      Not to say that COTS softwa
      • A lot of "outsourced" software is really hacked like mad. Often, someone will want a product, and a software company will have something sort of close, but the fundamental problem can often be the data model.

        So, instead of rewriting to reflect the bus. requirements, they shoehorn the data into the old system. I've seen this shit frequently.

        Another problem I've seen is that components/packages etc are only any good if they are truly that. Once you ask a company to modify the code for you, it's really no

    • 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).

      From articles posted in VR and CAD journals, Ford's advantage is being able to having the lowest design costs per product (measured in $ per day).

    • 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.

      I disagree. Whether you're buying software or producing it in-house, the actual act of obtaining functional code is barely even half the battle. Putting the code to proper use, i.e., implementing

  • Are you a software company? (Score:5, Insightful)

    by jafo ( 11982 ) * on Saturday January 22, 2005 @03:09PM (#11443141) Homepage
    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

    • Re:Are you a software company? (Score:5, Insightful)

      by alan_dershowitz ( 586542 ) on Saturday January 22, 2005 @03:26PM (#11443278)
      I've wasted thousands of man-hours messing with our in-house fee calculation app. Instead of just buying Oracle Financials, we had a bunch of PL/SQL hackers write a giant, poorly documented, database-driven general ledger. Fantastic. I'm sure someone thought we were getting off cheap, but I can't even hope to calculate how much money we've lost over the last 7 years due to maintenance and bugfix, not to mention lost productivitly due to the inflexibility of a system built by people that aren't even experts on accounting.

      The problem is that it's easier to convince bean counters you can make a "lean" custom app that only serves our needs _right now_, because it will cost less RIGHT NOW, than an expensive, but reliable and flexible USEFUL package.

    • Re:Are you a software company? (Score:5, Insightful)

      by Feztaa ( 633745 ) on Saturday January 22, 2005 @03:28PM (#11443297) Homepage
      At the risk of sounding like a zealot, Open Source is the obvious solution here. Most companies can just drop in a open source software package and use it as-is, much like they would for a COTS package. Companies who need customization can just make minor changes to the program, recompile, and voila! Best of both worlds -- you get custom software that meets your needs, but 99.9% of the development work is handled by the development community, so you don't have to start from scratch.
      • I've looked at this, and the one serious problem that my employer has with using OSS is the GPL.

        The simple fact is, at least with the nature of our particular business, any internal app has the potential to become a product that we sell at some point in the future. With this in mind, the GPL simply doesn't work. The bosses worry that if any of the tools that support our product become public domain, they can be snatched up by our competitors, thus erasing advantages our solution has over the others.

        For
        • I've looked at this, and the one serious problem that my employer has with using OSS is the GPL.

          The simple fact is, at least with the nature of our particular business, any internal app has the potential to become a product that we sell at some point in the future. With this in mind, the GPL simply doesn't work. The bosses worry that if any of the tools that support our product become public domain, they can be snatched up by our competitors, thus erasing advantages our solution has over the others.

          Obvio
          • This does not mean they can re-sell or give away the app; but they do have to give you any changes they make.

            Actually, I think I was wrong here. They only have to give source to any changes they distribute. But it'd be silly of them to not give back any changes, since they'd effectively have to maintain their own separate fork.
    • Eek what a generalisation.

      After working on projects with several so called software houses, eg Accenture, Oracle, EDS.... I cannot recommend them.

      Whether to customise in or out of the shop is very much a case by case thing.

      Criteria for me are how dependent on IT is the company, eg a modern bank will not out source its IT.

      Are you reinventing the wheel or doing something new/specific. eg no one in their right mind will write an inhouse word processor, but a business with pretty specific needs or requireme
      • Even after several disasters and a huge extra spend they keep going. They are scared to admit their mistake and have to manage/take control.
        That's the key. Most management is still stuck in decades past. They can't admit they were wrong, because they believe that doing so would doom their careers. They believe that management must be infallible and if it ever falters or admits to a mistake, disaster will ensue.
    • 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.

    • are you a restaurant? (Score:5, Insightful)

      by kpharmer ( 452893 ) * on Saturday January 22, 2005 @04:47PM (#11443819)
      > 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...

      • 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

        Most people have a pretty good idea of how to wipe. The number of people who can successfully write software is pretty limited. You might compare it to "why should you hire an airplane pilot... why not just sit at the controls and cross your fingers"

        The problem is that it's really easy to hire a couple of hotshots fresh out of school who are just sure that they know java and w

      • Gee where are my mod points when I need them?
        But seriously, the formula for success that I observed for many many years in the game is - custom applications built on OTS components/frameworks, preferably OSS frameworks.
        This gives you best of both worlds - good, custom solution and speed of development based on not reinventing the wheel.

    • 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.

      I have an instictive bad reactio

    • 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 d

  • Might be true for very large systems (Score:3, Interesting)

    by SamBeckett ( 96685 ) on Saturday January 22, 2005 @03:10PM (#11443146)
    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.
  • didn't Nike have a billion dollar failure using i2? So much time and money for a project that they eventually had to toss - it wasn't even close to performing for them as needed. Most out of the box packages end up needing so much customization that it seems to be easier to come up with a solution from scratch. At least that way your company will own the code and (hopefully) know what it contains.

  • Yes it is that bad. (Score:3, Interesting)

    by Anonymous Coward on Saturday January 22, 2005 @03:13PM (#11443169)
    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.

    • The real problem (Score:5, Interesting)

      by einhverfr ( 238914 ) <chris.travers@gm[ ].com ['ail' in gap]> on Saturday January 22, 2005 @03:37PM (#11443358) Homepage Journal
      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.

  • Egads (Score:3, Insightful)

    by onyxruby ( 118189 ) <onyxruby@cSTRAWomcast.net minus berry> on Saturday January 22, 2005 @03:14PM (#11443174)
    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.

    • Re:Egads (Score:3, Interesting)

      by innosent ( 618233 )
      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 particula

  • Yes (Score:3, Insightful)

    by briancnorton ( 586947 ) on Saturday January 22, 2005 @03:16PM (#11443185) Homepage
    Is the track record of custom built software really that bad?"

    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.

    • but people are never smart; lazy ness and incompetence are sop. this arguement that somehow software projects are more beset by lazyness stupidity or whathave you strikes me as not a good arguemtn for programmers to be advancing, even if it were true.
    • I've worked 3 jobs that were migrating to Siebel. The first two migrated about 1/8 of their people for 6 months for a trial phase. After the trial period, they gave their people prepaid Visa cards worth $100 as a thank you and apology for lost productivity. My current job is also migrating, but limited the abilities of their telnet backend so there would be no going back. It's just frustrating to have to step back into the 1980s every time I want a system to work and do so in a timely manner.

  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Saturday January 22, 2005 @03:17PM (#11443191)
    Comment removed based on user account deletion

  • Custom development realities (Score:5, Insightful)

    by JacobO ( 41895 ) on Saturday January 22, 2005 @03:17PM (#11443198)
    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.

  • Depends... (Score:3, Insightful)

    by j_kenpo ( 571930 ) on Saturday January 22, 2005 @03:18PM (#11443200)
    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.
    • It's about the requirements -

      #1. Did they even bother to collect them?

      #2. From the people who actually do the work?

      #3. While they were doing the work and not just what they could remember during a meeting?

      #4. Did they collect them over time? Some things happen:
      every day
      every week
      every 2 weeks
      every 1/2 month
      every month
      every quarter
      every 1/2 year
      every year

      #5. Did they do a sanity check of the information they've gathered?

      #6. Did they do a sanity check of how management wants to handle the data? (From TF
  • He seems to be taking the argument somewhere that it doesn't go. I don't see how you get from his good case for incremental improvements to making a case for buying COTS rather than developing stuff in-house.
    So sure, don't try to jump the whole stream at once -- your testing will be hard, you'll alienate your users, you'll spend a lot of money with no progress metrics, your risk is much higher. Look for stepping stones. But where is the FBI supposed to buy COTS to automate their workload? Spooks-R-US?
    • In fact it seems to me that monolithic proprietary COTS solutions might well be riskier than home-grown solutions, at least in terms of being too grandiose, alienating users, etc. A small in-house staff is much more likely to be able to make incremental, customer-drive, "organic" progress.

    • Indeed. Add to that that nobody gets to own COTS, they only get to lease it. Big homemade software are the foundation of successful businesses such as FedEx and Wally*World.

  • The pendulum continues to swing... (Score:5, Insightful)

    by bigtallmofo ( 695287 ) on Saturday January 22, 2005 @03:18PM (#11443209)
    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.

  • Mostly true (Score:2, Insightful)

    by JDOHERTY ( 323140 )
    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 te
  • My company [metatrontech.com] 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.

  • Pretty Accurate (Score:3, Insightful)

    by RevMike ( 632002 ) <<revMike> <at> <gmail.com>> on Saturday January 22, 2005 @03:20PM (#11443227) Journal

    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.

  • The 99% solution (Score:3, Insightful)

    by cperciva ( 102828 ) on Saturday January 22, 2005 @03:21PM (#11443232) Homepage
    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.

  • I have seen both ways (Score:3, Insightful)

    by ninthwave ( 150430 ) <slashdot@ninthwave.us> on Saturday January 22, 2005 @03:21PM (#11443233) Homepage
    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 agree... (Score:3, Insightful)

      by wasted ( 94866 )
      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-an
  • For every person that has a good response to a product, they might tell 2-3 people. That's "good" response, not "mediocre" or "satisfactory" - I imagine it'd have to be like coming out of the stoneage to a fully-functional system.

    For every person that has a negative response to a product, they tell 10 people (provided they don't have something invested in remaining mum).

    Thus, you're going to hear a lot more bitching about failures from people that didn't make the decisions.

  • CarrBomb (Score:5, Insightful)

    by Doc Ruby ( 173196 ) on Saturday January 22, 2005 @03:24PM (#11443252) Homepage Journal
    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.
  • 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
  • At my last job, the sales and tech support department hired contractors to build a new program for tracking orders, shipments, payments, bug reports, etc. Long story short, the project failed completely and they ended up paying money to customize the off-the-shelf system they'd been using for years.

    Maybe the best solution is neither just off-the-shelf software nor just custom software, but easily customizable off-the-shelf software. Of course, "easily" means barely doable by highly-paid well-trained contr

  • given the constant recalls that cost in the 100 MM+ range in the auto industry (as one example) one can only conclude that stupidity lazyness and incompetenace are rampant (not to mention poor spelling)

    or lawnmowers: i bought a 250 dollar lawnmower from sears last year, and "badly designed" is an understatement (not to pick on sears - just an example that comes to mind)

    or vacumn cleaners: for years, the american consumer had to buy house vacumn cleaners where there was a 2Cent plastic fan tht generated th

  • Depends... (Score:4, Interesting)

    by panurge ( 573432 ) on Saturday January 22, 2005 @03:32PM (#11443320)
    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.

    • I actually like your solution. Access and filemaker when people know them, make for decent prototyping programs even though they don't work well for production databases.

      People need to understand that getting good custom software (including customized COTS like CRM and ERP) needs to be done in stages.

      You figure out exactly what the requirements are. Then you create a prototype or first draft and figure out where it doesn't meet the requirements. Meet the minimal requirements first. Then make the small

    • 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 can only speak on the SME level, but I think most of the trouble with finding an ERP/MRP compatible with your business processes comes from not doing things in a way that's easily supported by automated systems, i.e. using the wrong philosophy. Companies that haven't done ERP before have this notion that the way they do things is the

    • You do realize that what will more than likely happen is that the small of proof-of-concept will be permanently adopted? What's more, you'll probably wind up holding it together with duct tape and string. I've seen several Filemaker apps deployed (painfully) on WANs and that had to be what happened.
      • They have asked me to manage the project, and I already know that if their sales growth goes as expected, they will not be able to use the RAD solution. I'm all too aware of the Filemaker to application gulf. But I do believe that this kind of prototyping is often more useful than paper modeling, because at the end of the day _you can import the data_!
  • Is the track record of custom built software really that bad?

    Not really, but the track record of project management is that bad, and project management of custom software is harder than implementing most COTS (if it's a reasonable fit).
  • ...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 prod

  • In a nutshell (Score:4, Insightful)

    by Todd Knarr ( 15451 ) on Saturday January 22, 2005 @03:39PM (#11443367) Homepage

    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.

  • I agree completely with the article IF the company in question has the self discipline to buy some piece of COTS that does %80 of what they need and...


    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.

  • Fill in the gaps with custom software (Score:3, Interesting)

    by CharAznable ( 702598 ) on Saturday January 22, 2005 @03:45PM (#11443411)
    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.
  • 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.

  • COTS seldom works (Score:5, Interesting)

    by ColoradoRancher ( 526612 ) on Saturday January 22, 2005 @03:49PM (#11443445)
    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.

  • 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 politicall

  • It's Not The Software (Score:3, Interesting)

    by Master of Transhuman ( 597628 ) on Saturday January 22, 2005 @04:08PM (#11443599) Homepage

    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.

  • Trick question. You do whatever fits your situation the best. I will say that custom programming business applications has been the most trying, except for those situations where you're using COTS and are bending the business process to fit the software.... 8P

  • COTS vs Custom (Score:5, Insightful)

    by Liquidrage ( 640463 ) on Saturday January 22, 2005 @04:11PM (#11443619)
    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.
  • Commercial software is convenient in that it is typically easy to install and configure almost the way you want it, but that's where the honey moon ends. Everything else about it is bad. Oh, sometimes there's technical support available, but generally it's horrible anyway.

    On the other hand, there is all this open source software available, most of which won't cost you a dime unless you need support. And, if you need software changes - as others have pointed out throughout this thread, you can have them do

  • --> From The Register [theregister.co.uk]
    HP suffered one of its more embarrassing recent episodes when an internal SAP consolidation cost it $400m in third quarter revenue...But how forthright was HP? During its third quarter earnings call, the company was typically hesitant to say exactly what went wrong with its ordering system. Only later, did word leak out that a failed SAP consolidation was to blame....Many insiders knew the project - code-named Fusion - had every chance of going wrong, despite HP's supposed expertise
  • If you produce a large system entirely from scratch then you need to be prepared to add features, and do other maintenance to that system for as long as it is used (maybe decades.)

    If you customize an existing COTS package then you need to be prepared to maintain at least the portion you customized. (And hopefully you kept your customizations modular so you could still upgrade the underlying COTS software as new releases come out.)

    If you start with FOSS and customize it, you can probably get some of you

  • I work for a large industrial insurance company. While the network infrastructure is Windows; workstations, AD for authentication and IIS for web applications, almost all the core business software is home brew. And it's awesome.

    We have applications for all our insurance systems. Risk management, site surveys, customer accessable information, everything. It's all built in house. We have over 6,000 employees total; several hundred being IT staff and development teams.

    I couldn't imagine us using an of
  • The article author is right. Software has long passed the stage where programming involved art, or even craft; now, mass production is the mainstream. The software field has matured to the point where it has become mundane -- just as car manufacturing (Ford), cooking (McDonalds), music (MTV), etc. When you have mass production, it makes absolutely no sense to painstakingly build your own solution, where readily available, time-proven copies can be bought off the shelf for cheap.

    Innovation (the real kind,

  • in theory we develop software, offer a "lite" version for free, maybe make it under an open source license. Make a "pro" version and charge money for registration, the "pro" version has more features than the "lite" version.

    If the customer wants a customized version, we can offer services to customize the software for them, at so much per hour. If they want to customize it themselves, they can purchase a license to do so and release it from our license and develop their own version of it for their own pers
  • Or _A_ reason, anyway, is that the customer insists on not changing their business processes AT ALL. The new software has to do everything the old system did, in the same way. And often this just doesn't make sense; either the very reason the customer wants new software argues for a different model, or other considerations argue for a different model. But the customer dangles the money in front of sales, sales promises, management dictates, the programmers write -- and what you end up with is a system wh
  • Having been involved in a couple of in house enterprise projects and having spoken to dozens of local developers on the subject of failed and successful projects, IMHO the three major reasons for large in house software project failure are:
    1) Starting a project from scratch staffed by only inadequately experienced developers;
    2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
    3) The Vendor Dependent Death March : When in house projects are dependen
  • Company buys COTS package.
    Company realizes the COTS doesn't do half of what they need it to do.
    Company builds a customized hodge-podge of scripts, glue, interfaces, and translators, around and on top of the COTS. If they're lucky it will sort of work for what they need to do.

    Result: the worst of both worlds. The labor and time costs of customized software, with the inflexibility and vendor-dependence of COTS.

  • A tale of two (Score:3, Insightful)

    by BCW2 ( 168187 ) on Saturday January 22, 2005 @07:31PM (#11444740) Journal
    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.

Slashdot Top Deals

In order to get a loan you must first prove you don't need it.

Close