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
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.
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.
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.
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.
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.
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.
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
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.
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!
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...
Is that what Enron did? :)
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.