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?"
For literally years, the "editor" "michael" has been splattering his moronic influence all over this website. Now, if Slashdot were some dipshit site without any effect on the online world, that'd be all well and good, but I and I'm sure you too would agree that as editor of the most popular "News for nerds" website, michael has a responsibility to us. Amongst the many things that michael has done are:
The list goes on and on. michael must go. Slashdot's not that great as it is, but he's just dragging this place down all the faster. What can we do? Taco ignores all emails about his beloved $20K-a-year staff; he trusts michael more than the opinion of his beloved readers. Taco won't do a thing unless we can hit him where it hurts - in the pocket.
How? Simple. Taco relies upon the insightful-sounding commentary that this site occasionally produces. (You'll notice he doesn't go to the trouble of modding it up himself - he leaves it to us!). Without it, people stop visiting and Slashdot becomes unprofitable. So, here's what to do if you want to oust michael and force Taco to fix Slashdot:
Certainly has a lot of PHBs scared. I know of many places where everything is outsourced and only standard products.
Customise it ! Do it in-house !! Are you mad !!!
To the extent these companies are spending a fortune rather than in-house and customise/support their business processes
No Karma Whoring. Eat it up... NY Times Article
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.
...finished on time, and under/on budget
I dont know if its because the goalposts are always shifted mid-project, or just that the companies consider the initial tendering more as a chance to get the job in the first place, instead of putting in a realistic price for completion
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.
I think what the author is trying to come across with, and what is the most true, is that most companies like to jump on board rather fast at developing their own custom made solutions, especially when there is already a product out there that solves the problem.
As a small times software developer, I have been on several custom software projects, and these have a high rate of failure and tend to go quite over budget. For example, one particular project I worked on was to be a slimmed down replacement for quickbooks because the business didn't want to purchase quickbooks licenses.
To put it bluntly, the final product cost them 10% more than what quickbooks would have for 10% of the functionality. That is not ver economic...
However, there are plenty of circumstances where custom software is the best solution, one just has to be weary to know if the project may just be a Death march project.
Cheers,
James CarrMaybe, just maybe, that while working on the in-house solution, they found out that the business process was so complex it would be better to review the business process to simplify it instead of trying to modelize it.
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.
Is the track record of custom built software really that bad?
Yes.
Since this is in the HBR, take for example the custom-built payroll system Harvard University paid PeopleSoft tons of money to make for them. It failed to pay people accurately.
The university had to send out a notice to everyone telling them to double-check their paychecks make sure they hadn't gotten paid too much or too little. This went on for months. Oh, but it was web-enabled -- they were really proud of that! It also required IE to use -- at a university, where non-IE usage among primadonna users is high. Talk about not meeting requirements.
I don't know that you should never develop in-house software, but you should never, under any circumstances, pay a company like PeopleSoft to write something for you. The above is just one example of millions of dollars given to them for something that does not even work.
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?
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
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.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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
There wouldn't be a problem if more applications had development documents and a method of adding custom plug-ins. You would get the best of both worlds - an off the shelf product with custom functionality.
Back in my intern days I wrote a lot of VB for Application scripts for Word and Excel for an investment firm. They chose Word and Excel in those days because the competition didn't have anything like it at the time.
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.
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 contractors.
What a fool believes, he sees, no wise man has the power to reason away.
HR
Accounting
Inventory management
Payroll
etc.
We're using The Vexi Project to design our customer service, sales and call tracking system (essentially the core of our office systems). We are doing this instead of relying on technologies centered around existing systems because, frankly, all you get with COTS is a shortcut to dependence on a disinterested third party.
We're not Ford. We haven't got the pull of someone like Microsoft. We have been bitten in the past by COTS software (oh, AutoCAD, AccPAC, Microsoft for starters) -- support contracts went up in price every single year and the problems/bugs resolved were trivial and inconsequential while the larger problems were glossed over or promised "in the next version." And then of course you get to the beloved statement of "We're end-of-lifeing the product. Sorry about your luck."
With OSS this just does not happen. In fact, I would go so far as to say it's impossible. With Vexi, the engine is open source and runs on multiple platforms (Java and then native Win32, Linux and OSX). We didn't go the DHTML route because now you've tied yourself to a browser. We've hired a contractor (in fact, one of the driving forces behind Vexi) to continue developing the widget set and work away at the engine while writing exactly what we want and in the end, it is ours. We can try to make it a COTS system and sell it (not likely), we can expand it either by writing the extensions ourselves or by hiring him again (or anyone else) and -- here's the best part -- nobody can take it from us. We don't have to worry about retooling when the company gets bought out (SSH Sentinel) and, as I've said before, as our business grows and changes so can our software.
You simply cannot get that with COTS. We've been there and done that and in my opinion it's a very bad thing to do -- to put your core business flow into someone else's hands. No two businesses run quite the same way and this is the exact reason why there are a hundred different COTS systems trying to be "the one."
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 the airflow that generated the suction, and thefan was placed BEFORE the filter, so if you sucked up a penny, crack, no fan blade, toss the sucker.
then some braniac figured out you could put the fan on the other side of the filter
check out the history on this one.
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.
I've have done a lot of thinking about Carr's original article, and I only 1/2 agree with him. I think he's absolutely correct for non strategic things. But, if it's something strategic, that you're really supposed to be good at, then how can you just use a packaged app? You are ensuring you are going to be mediocre at that particular thing.
For example, I work for a software company. I wouldn't dream of using packaged development apps / case tools (think Rational). if we can't do it better than them, we shouldn't be in business.
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
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).
Don't disappoint your bird dog. Go to the range.
...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.
Yes.
If I ran an office, and could only hire highly skilled computer professionals for every job position, I would definitely go for the generic off the shelf products.
It is all percetion. Expensive one trick pony, or a cheap off the shelf extensible solution. Sounds like an easy decision.
Until you start getting bad data because there was no error checking.
Until you 20 users in one access VBA app blow up the database.
Until you realize your business unit is spending all their time trying to learn how to write a macro to turn Word into a Spreadsheet instead of actually making business decisions to make you money.
Haven't read the article though - too lazy to register at NYT. - he
Business managers are like any other employee subject to scruteny from the board and the shareholders. What do you choose? Adapting the software to suit your business model? Well - it is called software for that reason, but what if your business model isn't perfect? Then the software won't really work and maybee - just maybe - it will uncover the imperfections of your implemented and already running model.
Buying COTS means that you must adapt your business model to the models used in the software. Those are big companies so board and shareholder are more likely to pony up the amounts needed to convert to that model. Nobody asks the two important questions:
1) Does your business fit into the model?
2) Does the model work at all?
But in the end: "Who has ever been fired for ordering IBM"?
All that is now left is to complain about the maintenance contract fees and clauses. And that is not really your fault - or is it?
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.
one of my pals was involved in a large COTS customization project for a major county in california, USA.
the project was supposed to umbrella/eliminate a huge number of custom small HR, accounting, business logic apps that varied by city.
when the project finally imploded/failed, it was 2X over time and 2X over budget.
why ? not the engineers. the development team had done the same thing for several corporations and although they were occasionally late and sometimes over budget, every previous job was considered a sucess...the customers were ecstatic.
it was the beaureaucratic mess of trying to get all the cities to agree on a set of business logic. everyone demanded their own logic be thrown into the pot. it was a nightmare, because while a corporation can dictate things, there was no person or group powerful enough to put all the cities in line. this was the first time the team tried to do custom cots for a government entity, as opposed to a commercial entity.
end result : a huge failed project, one that has made the papers several times, and every single article blames the contractor and the developers, the complexity of software, the usual claims about developers being unmanageable, overpaid, etc.
so, as usual, take everything you read about cots vs. custom with a huge grain of salt. the author and editors usually have an axe to grind.
finally, the idea of cots vs. custom is blurred in a lot of ways. it's rare to see anyone write a custom OS for an application anymore, although it is occasionally still done. similarly, the toolkits are more powerful than ever...so making some blanket statement about cots or custom is really kind of stupid. it's so dependent on the problem domain.
What we do where I work, and it works well, is to use off-the-shelf products wherever possible. We do make sure that the stuff we get has some level of openness, so that we can build custom stuff around it and customize to fit what we do. An ERP, for instance, can't account for all your business processes. Chances are your company has something unique about it that can't be accounted for with off-the-shelf software. Hopefully you can account for that by building custom stuff.
The perfect sig is a lot like silence, only louder
I've worked for Ford, I've seen many project scrapped. It's incompetence in Ford's IT management that's the problem.
DCAS, FocalPt, hundreds of millions wasted on bullshitters, many many incompetently run projects have never returned their money.
I've also done many very successful custom IT projects.
So it's not right to judge project's based on Ford's incompetence.
Sure, using COTS makes sense if it does what you need. No one disagrees.
The difficulty is that answers to big, complex problems usually aren't found in a box. Before someone can give you a solution, they must have first envisioned your problem.
A better strategy is to have an infrastructure upon which various solutions can be developed independently and in parallel. Take the Internet, for example: a common infrastructure with, at first, only a few solutions, but now, with millions.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
Everything I've experienced has taught me one very clear lesson: COTS does not work, for anything beyond a mail client or a suite of 'office' tools. Your internal business critical applications must be custom developed. And when custom developed, in-house development fares better than contracted custom devo.
I've noticed that COTS always seems to look better on paper, and starts off with a lower price tag. But even in the first week of deployment, that biz process you tried to bend to fit the software, just doesn't work when bent that way. So you start to loose business, or you have to modify the COTS software. Usually both. After a year, if you haven't gotten smarter and scrapped the COTS software entirely, and if your business unit is clever enought to stay afloat after that bad COTS decision, you find that you've had to customize it so much that it doesn't even look like the original. Oh, and surprise!, you've spent at least triple what it would have cost for an in-house development effort.
But wait, it gets worse. Eventually the COTS software just can't be customized any further, and must be scrapped. Your good developers... er, 'customizers'... see the ship is sinking. Most of them jump ship to the company that produced the COTS software, so they can do 'real coding'. Now you're doubly screwed.
I've seen both custom and COTS solutions succeed, and I've seen them both fail miserably.
As a number of folks have pointed out, the PM/planning/Requirements gathering has a huge amount to do with the eventual success. As does the willingness of the users to actually adopt the system.
You'd hope the if you involve all of the stakeholders at the right point they will buy into the final solution, but in reality, the corporate politics can kill a technically exellent solution more effectivly than a politically supported but technically weak solution.
If people have some degree of buy-in to a solution, they'll overlook a lot of v1.0 warts. If they hate it for political reasons, they won't rest until those responsible for it have been sack, the people who sacked them sacked, and so on...
unfortunatly, this usually leaves the user community (e.g., the company) in the same or worse mess than they started.
I 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 smallest possible changes necessary to meet the other requirments (in terms of lines of code).
If you try to do everything all at once, you are in for a train wreck of a project as you will have too many problems to solve at too high a business oportunity cost and will never get it finished.
LedgerSMB: Open source Accounting/ERP
COTS can be a really bad idea when the religion of COTS is interpreted as the religion of never writing any of your own code. One such organization I know hired contractors to write software from scratch and call it COTS. Business process owners never have an easy time of explaining software needs and requirements to anyone, now that the programmer is outside of the organization, 300 miles away, the risk of a gap between needs and final code is no longer a risk, but a certainty. At least COTS will remove that risk from software development. In the COTS only organization, desperate line managers resort to using non-programmers to write code, random staff writing their own MS-Office applications, using VBA, secretaries using Excel to hold databases, and all the other horrors that could have been prevented by rejecting a COTS only policy and allowing professional internal developers to do their thing.
(notwithstanding non-"business process" related stuff, like OS's, word processors and so on should never be written in house, that would be reinventing the wheel)
If you have a functioning business it will be because it has a competitive advantage. The business rules which define this will be necessarily unique. To that extent you have no choice but to customize. Good engineering practice is to attempt to limit customization to those business rules.
Typically this will involve not buying all-in-one products but libraries and server-software etc. Certainly you don't want to write your own DBMS (unless there's something peculiar about your data that warrants this) but you will still have some work to do.
Right now, the organization I work for is dealing with two really crappy pieces of software. One is built around prepackaged software (MS SQL, IIS 5, with minimal custom programming on the client end and backend). The other is completely custom from client to backend with the exception fo the Oracle DB which is more or less used as a file cabinet.
What it really comes down to is whether or not you have decent programmers and engineers working on the software. The problem is that there are not that many good programmers or engineers in every business that writes software.
In our case, the software built with prepackaged and slightly modified software is responsible for controlling people's logins on public internet computers as well as tracking their printing so that we can charge them for printing. This company has tried to make the software work easily on the user end and staff sides, but they've completely ignored the administrative side. It's been a nightmare to deploy this software or manage it. This company's ides of remote management is to get the end users to WebEx into them! They also chose to interface with a user database by actually copying the user database to yet another DB server thereby guaranteeing that their DB will alwasy be slightly out of date. Complete idiocy. But they are also pretty much the only game in town. We're stuck with them whether we like it or not. I'd consider the idea of in-house homegrown software to do this, but it's not my call.
The other company writes very specialized software that is 3-tier client/server. End-User Client Application Server Oracle DB. The client and application server are completely custom written and Oracle is only used as I said before as a file cabinet. The end-user client sucks about 14k per user from the network. We have almost 1000 users. You can imagine what this does for our remote ends (about 60 offices) who are on already overloaded T1s. The company who wrote this monstrosity have absolutlely no clue of the needs we have as an organization. But... again, they are the only game in town and, believe it or not, they aren't the worst of what is out there. The implementation of this software has been a trip through hell from day one and probably won't be stopping any time soon.
I don't think the problem is the approach of either company, but I think it's due to the fact that they only really have one or two programmers that are any good and those guys are being spread thin. The rest of the coders probably mean well, but really can't grasp what it is we need. So, don't get your panties in a bunch about which approach is better or worse. They both suck if you have very few decent programmers and/or engineers.
IT Doesn't Matter
Article Text
The open source community needs to find a way to move into the business application sector in an effective manner. I don't believe that it will be by using low-level tools like .Net or Struts. It needs to come through leveraged frameworks like Compiere, Spring or Open for Business.
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!
Interesting that while Ford's supply-chain-mgmt problem is probably a wheel that's been rounded and smoothed by thousands of other companies, and for which several reasonably customizable COTS solutions actually exist, the FBI's problem is not so common. Is there a COTS solution for their problem? Not likely, nothing that would scale to the size of the FBI's needs, and provide them with the security that they'd have to have.
I'd bet that any solution they have been working on is chocked full of COTS products, which are being integrated. COTS products that have been chosen for their buzzwords and kickbacks, not for applicability, stability, scalability, or likelyhood to be supported when the system actually goes live. The government buyers LOVE to hear COTS products bid on their projects.
On the other hand, what I love is when COTS A version y runs on backend COTS database B version x, and they both run on OS version z... but you need to upgrade OS version z to a new revision for COTS product Q.. Of course, new new OS version is supported by A, but not B. Remember, those vendors follow THEIR product cycles, not yours. Then you end up paying through the nose for support for an "obsolete" version of the COTS product or being on an "unsupported" configuration, at which point something goes wrong, and the vendor tells you "well, we don't support that configuration, call us back when you're running a configuration we do support."
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
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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
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 done, usually for reasonable rates given the abundance of out of work programmers. If I were starting a business today there is no way I would willingly hand myself over to Microsoft's less than tender care. If I were looking at an extremely outdated enterprise I might also think seriously about moving on to Linux. If you truly need your legacy windows applications you can get them through the use of virtual machines or wine as appropriate - it basically depends on how well-behaved they are. Don't ever assume a windows to windows migration is easy - it ain't necessarily so.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
--> From The Register
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 in dealing with SAP migrations....High-ranking executives were being forced to spend their time approving rush orders of $50 parts to key customers. In total, a disaster - and not one that HP described in exacting detail to the public.
It has been my experience that sometimes IT is left out of the process of selecting a solution for the company. Leaving the decision making to burocrats who know jack sh@t about computers (a Mac scares the crap out of them). For example Who the heck would buy SAP for a college!!!!!??? Millions of dollars in a big fiasco that creates ten times the work for people!!!! But it looked nice when the consultants presented it... right? It's like when you go and buy a car, the sales man asks yuo how much you want to "pay" and he sells it tou you for just that... a month plus all the little nasty things in the small print, extra charges... People, administrators, burocrats, etc, don't understand that if they don't know what they are doing they can ask their OWN IT DEPARTMENT and not a stupid consultant that is simply a salesman. (Note: not all consultants are bad, I know. I am one and I am also part of the IT in my second job)
===== "Every head is a different world so don't invade mine you FREAK!" smartSAGA said
...at least not in security software. Particularly in this consolidation age, companies can't ever get their own library to interoperate, much less get their stuff working with someone else.
Yes, they killed the COTS solution and went back to purpose-written custom software. Why?
That hardly supports a decsion to go with COTS solutions. 'Nuff said!
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 your changes merged back into the main project (so they automatically are included in every future release.) Then you have to plan to maintain the portions you are keeping hidden inside your company.
If you can find a COTS (or FOSS) package that fits your needs exactly (or nearly enough that you don't have to customize) USE IT!
The maintenance issue really kicks in as you move on to custom project #2, #3, #4.. etc. Unless your IT staff is growing along with the maintenance needs, you'll soon find that all of your time is spent just fixing and keeping existing stuff working.
"It's the management that is the problem."
Read "The inmates are running the Asylum." by Alan Cooper, and you'll find that the problems really are with programmers.
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 off-the-shelf product for those duties. While I suspect that the quality of the code in our applications might not be as high as a software-only company, we do it right and have plenty of people on the job to support the apps. Our edge comes from the fact that we have the most usuable system for both the company and our customers.
On the other hand, if you can't support a full in-house development crew for an application you need, you'll need to get an off-the-shelf application. You can buy commercial applications, or, if your needs can be met with an open source application you could use that.
The great thing about OSS is that you can use the application and you can staff a very small crew of developers to customize it to your needs. It's not re-inventing the wheel, and you still get what you want. I see this as a trend going forward.
Of course, most of this applies to a larger company. If you have a small company chances are you'll need to buy a commercial app and be at the mercy of the company that produces the application.
Custom software will always exist because every company is different. While you can change your business model to match the software, it can only take you so far.
That's my thoughts on the subject.
- It's not the Macs I hate. It's Digg users. -
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.
Innovation (the real kind, not the MS kind) still has a place in software, of course, but it only matters for software companies, and a few highly specialized scientific applications... Basically, innovation only matters for companies who are actively involved in some sort of research (software research, biology research, etc.). For regular companies, pre-packaged solutions for common problems (payroll app, office email app, company webserver, shopping cart, whatever) are much preferable.
Think about it this way: would you rather build your own car from nuts and bolts, or grow and slaughter your own chickens for food, or sew your own shirt from textiles that you made yourself ? No ? Then why write your own software ? Unless it's purely for fun, of course...
>|<*:=
"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."
As part of that four decades. Did you ever see OSS play a role? If so did it mean that COTS still doesn't work?
I have watched a large organisation go through "hell on a stick" trying to make a PeopleSoft staff support product actually work. Years down the track and the human resource system is still over-promising and under-delivering.
The number of work-arounds needed by the staffing practitioners is unbelievable. That is where the innovation lies.
I suppose that I should not blame PeopleSoft too much. I can't remember actually speaking to any of their developers. However, it was probably the case that the sales talk had been so successful that the internal front-line people implementing the system had believed the pitch and then over-promised.
What we practitioners saw was the basic PeopleSoft product having to be heavily reworked for months and then years to make it do the kind of thing our organisation needed to do, and know about itself.
I kept wondering whether PeopleSoft had actually analysed our information requirement before tendering: I'm sure that our organisation would have explained its information requirement in tender documents, because that's how we do things.
Looking at space, radio, science and computing from a 'down-under' amateur enthusiast perspective.
> 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...
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 personal use, in that case they are responsible for the maintenance and upgrades, and we can share code with them.
I am thinking of a BSD License to do this. The "lite" version being the core program, and the "pro" version having more bells and whistles, etc.
The "pro" version can be the COTS product, and the "lite" version can be the OSS product, and the customized version the custom software product.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Risk of Software Project Failure = ((NumberIncompetents/TotNmbrInvolved)x .4 +
(1.0 - ($Invested/$ReallyNeeded)) x .2 +
(1.0 - (DaysInSchedule/DaysReallyRequired))x .4)
x ChangingRequirementsFactor
Just wondering... is this bad rep with custom software based on projects before 2000?
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 which is extremely clunky and inefficient because it's basically simulating the old system (which wasn't good enough in the first place).
With COTS, the customer doesn't have that option so they are forced to give a little. Of course the danger THERE is that the COTS software simply can't support what they want to do.
instead of writing large monolithic things and then whinging that the vendor doesn't support some random feature, the hardware people have it much better off.
.... in hard macro, soft IP, or discrete parts. i get to decide which parts i need to build, and which i can buy off the shelf. and when i do build something, a chip, a function, or a board, there are well-recongnized processes to make sure its going to work as expected, and effectively bound the schedule slip.
... nothing.
i can buy 100s of different kinds of DACs, or adders, or crossbars, or
in hardware, testing and schedules are not a joke. and every decision i make has to be justified economically.
and in software...i can sell my soul to some huge ERP vendor, and end up with nothing. or i can fire
up an internal software group and end up with
the model is all wrong. its all about composition.
for some reason we just haven't learned that yet.
> "When it comes to developing software today,
> innovation should be a last resort, not a first
> instinct."
"When it comes to developing software today,
innovation should be a last resort, not a first
instinct - so buy your software from the company that doesn't innovate, my sponsor, Microsoft".
IMO, this article is an indirect attempt to rebutt one of the advantages of free software - that a company can share the development of the non-differentiating parts of software development with other companies, and customise what they need for themselves in-house.
That most off-the-shelf software products start their life as successful custom apps?
From what I've seen, the life cycle goes like this:
1) build something to solve a specific problem
2) modify to solve a few problems
3) modify to solve similar problems for a few different clients
4) try to modify to make generic enough to sell
5) lauch "off the shelf" package
Of course most project die somewhere before hitting the 5th step, mostly for all the reasons already mentioned. I've worked on projects that have stopped at every stage, and also some that have made it to commercial success.
I don't think I can recall a good product that started life as a commercial package that's been started in the past 5 years. Can you?
The main problem I have seen is that a lot of people can talk a real good game but very few can actually develop useful software.
I have been involved with COTS installations that failed and custom developed systems that worked great and vice versa.
One system is not better than the other it is simply the skill of the people doing either.
What this and other similar op/eds fail to realized (and unfortunately what more and more execs fail to realize) is that off-the-shelf software is anything but a boxed finished product. More often than not (there are exceptions) the product is a poorly architected skeleton that doesn't really fit the need it was purchased for. The "integration" projects are really rewrite and square peg round hole projects and in the end you pay 80% of the cost of building and only get 30%-50% of the functionality (or at least the functionality that was key to your business...lots of times you've got a bunch of useless extras). Buy does save money versus build, but it also fails to deliver MUCH of the time costs way too much for what it does deliver and results in regret costs are an order of magnitude higher with an off the shelf product.
HR, CRM, Payroll, etc. (i.e. systems where there is no or little competitive advantage to innovation and you can gain a much higher functionality fit than the normal 50% or less because everyone does this stuff the same way) are excellent targets for that 80% cost reduction. Just be prepared to revamp some buisiness practices to match your new industry homogonized system.
Though there are places for bought software in the end if it is core to your business for goodness sakes build it. Some of the best systems in the world are at investment banks. One of which I have intimate knowlege of has a constantly evolving software infrastructure that means they only build about 50% of any system and leverage the infrastucture for the rest. In their case they actually save money by building and they get an exact fit. To do this though you have to invest millions up front, which they did.
As with most things there is a place for both and both are good at different things. Just be aware that Mr. IT Doesn't Matter has an agenda to sell business books to big time C-Level execs so the more outrageous his claims the better and more guru-ish he sounds as long as they contain just a kernel of trough that he can use to show as examples of why he is right. Like everything else caveat emptor.
#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 TFA: Why would the executives be concerned with the oil for the fries? It's called "delegation".
#7. What are the legal requirements?
#8. Have you documented the reasons why you did something the way you did it?
#9. Have you documented the reasons why you are not providing certain functionality? This will come up in the future. Feature creep always happens.
#10. Have you evaluated commercial products and documented why they weren't sufficient?
Doing requirements is a LOT of work. But if you don't know what you need, how will you know how to build it?
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 dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
The article, which is quite short, is more about the commonality of large software project failures than about the COTS / custom software debate. The author is talking about projects worth $170M; everybody knows that in this range, the project cost comes mostly not from licenses of "COTS" software but from implementation costs anyway!
In fact, COTS doesn't really mean "off-the-shelf" when you're talking about software like SAP for which every $1 paid in license fees must be complemented by $2-$5 in implementation cost / consulting!!
The rate of failure of these big projects largely qualifies the software industry as "immature".
Sure, there are other industries for which going overbudget or late is routine. Take the construction business, for one--and that's one of the oldest trades, so it is not really a question of maturity. 20 centuries from now, chances are builders will still always be late on schedule and overbudget. But at least, in general, you have a roof and four walls when you spend $170 million on a building!
Not so with software, where such large projects are trashed one after another--or even "smaller" corporate projects in the $1-$2M range. I think that's still amazing.
I would attribute this to the computer illiteracy of many of today's executives; not wanting to look like they don't know jack about technology, they gobble in vendor bullshit and are afraid of asking even the "dumb but obvious questions"! They should, and then they should keep that money for something else!
Btw if some big-ass corporate exec out there wants to give me another couple M$ for nothing in return, feel free.
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?
that their off-the-shelf "E-Business Suite" was custom developed by Ford.
Isn't all software custom, by definition? Carr has again demonstrated his stunning lack of perception by treating software as a product. I'm sure this forum, as well as FASB, recognize that software is better viewed as a service (recorded procedures) or as a knowledge system. Adam Smith's vision of perfect capitalism with the associated low margins is prevented by adding value. Adding value adds margin. The struggle is to obtain competitive advantage. This is often done in mature industries via better systems and better market knowledge with quicker response to c hange. Carr's vision would have us all running SAP/Oracle (after their merger) and driving those stupid Minority Report/tron-esque Lexus with only CxO's making any money.
I was looking for an appropriate post to reply to to state this observation, and this one will serve as well as any.
We can all sit behind our keyboards and debate the merits of COTS vs FLOSS vs whatever.. but at the end of the day, it's all moot. The problem is that when an enterprise is in a position to make a decision of buy (and customize) vs. develop, the people making the decisions will be the ones least qualified to do so. Selecting critical business tools is not a trivial undertaking, and it involves non-trivial amounts of money. And ultimately, fixed initial and recurring costs (in addition to politics and personal connections) are what make these decisions, not the merits of one approach vs. another.
And IMHO this is where FLOSS is at a disadvantage. Your average CEO (and, sad to say, most CIOs) don't even know about open source. You say "open source" and they'll ask you how a computer thingy can have an open sore. Even if (hypothetically) there are significant advantages to an open source strategy, the effort required to get the people who sign the checks to understand the concept of "free" software is frequently far above the ability of most IT people to make. (If they're even given the chance; most executives cannot think in terms of value, they can only think in terms of cost. And if it's free, it can't possibly be any good.)
As an example, let's say Acme WidgetCo needs an inventory program. Vendor A has a solution that meets 80% of the company's needs, and the product costs $100,000. Vendor B has a solution that meets 90% of the company's needs, and the product costs $150,000. Vendor C has a solution that meets 50% of the company's needs, and costs $200,000. Developing the software in-house to meet 100% of the company's needs would necesitate the hiring of additional staff and consultants, at a cost of $125,000 over the development cycle of the product.
Vendor C will get the contract, in defiance of all logic, because Vendor C's CEO plays golf with Acme's CEO.
Merit has nothing to do with this decision. Politics and connections make these decisions. The people who do the actual work just have to clean up the mess, and the company rewards their hard work with poor performance reviews because the software is complete crap, even though no amount of effort could make it otherwise. Sadly, this is considered a benefit because it keeps salaries down.
Never underestimate the power of stupid people in large groups.
As part of a company whose services include providing custom applications, I rankle at the article's implication that custom software is rarely worth it. This over-broad conlusion is simply wrong.
Granted, if you run on a cookie-cutter business model, you can use COTS for everything you do. But if you're going to do anything innovative business-wise, well-implemented custom software can be crucial to your success.
The author seems to want to scare people away from custom software by citing the flushing of millions of dollars by corporations on poorly-executed projects. Admittedly, at that scale, you'd better be clear on where you're going and how you plan to get there. Custom software generally provides better value the smaller it is, and the more specific it is to a clearly-defined business problem.
At smaller scales (i.e., not funded by multi-million dollar corporations), custom software can and usually does succeed. It can also succeed at larger scales, and has...the article just doesn't cover the success stories.
Furthermore, if you are a funder of custom software development, making sure you own the code that is produced for you means that your investment can be salvaged when the developer blows chunks. Open Source platforms tend to fit well with this model of vendor freedom.
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.
---------
There is inferior bacteria on the interior of your posterior.
If a system or service is strategic to your business then build it. If it is tactical, then buy it.
Ford's supply system is tactical. Amazon's feedback system is strategic.
I work for my Dad in the family business. We have our own piece of customer software that is coded in VBA in MS Access (I can see my karma dropping) .ADP front-end for MS SQL server. It keeps track of nearly everything in our organization. All our customer's contact data. Their BTNs/WTNs (Billing & Working Telephone Numbers), their SSNs... We scan in all the paper applications and they are attached to customers' accounts. We have a reminder list. The whole system is tightly integrated with the various carriers we work with. With one carrier, a click of a button will automatically log the user onto the carrier site and one more click will pull up the current customer's record. With another carrier, I made an auto import feature from a CSV spreadsheet. It is, of course, only a click away. Recently we started our own calling card. I spent about 1.5 days and now we have a billing system. Recently I totally automated the commission report and commission checks process that we send to our sales reps. It used to take 4-5 hours by hand. It exports the checks to Quicken. I did all the coding in 2 days. I could go on and on.
I cannot imagine finding any off the self software that could do what our piece of software does. (I know it's MS based, but it gets the job done efficiently; the boss'd (my dad) never let me go to Linux for desktop environments. He resists the idea of using a Linux box for a firewall. We paid $700 for an industrial strength off the frickin shelf firewall which crashes all the time and disconnects our VPN users.) Whenever a new business opportunity or wrinkle comes up, we can implement it easily and efficiently. You must think at this point that we are a big corp. Nope. I am the sole full time employee. Dad works in Communications part time (he has multiple businesses) and we have another part time girl. We have a lot revenue/profit because of residual commissions from 15,000 customers.
If this were a poll, I would vote custom software.
Read my blog: HansMast.com
Every single custom solution we use is terrible. Further, their upkeep seems to be a bridge to far. A few years after they go online they are out of date with no hope of getting someone to spend their life reworking it. Star office, Microsoft office, SQL, almost anything out of the box open source or not is better than a custom-built-just-for-you solution. I agree with the premise.
But some things are just better done low tech. This guy had a point, but he lost it in suggesting commercial software.
I keep business cards. Computerized address books are just too cumbersome for me to integrate in all of the places I want them to be available. Eventually they fall out of sync and become an annoyance to deal with.
I pay bills by check, the checks are written out in ink. I don't set up direct debit with my vendors since errors are such a PITA to address. I use ink to fill the checks out because I don't want to maintain check writing software. Seven ring binders were the greatest discovery of 2003 for me.
Financial records are all kept on paper. Syncing income/expenses to a computer is tedious. I used to scan invoices but that got tiresome and I didn't want to maintain scanners or scanner software. Now I have file cabinets, with files in it. The files contain invoices and other records. I can pull them up pretty quickly, and it breaks up my day to get up and fetch them. :D
I keep about an equal number of note files that I edit with vi, and notebooks that I fill out in ink. About the most high-tech thing I do in business is ssh into a shell account to check my mail and update notes.
I'd rather call someone on the phone or have a secretary do the typing over sitting down and writing some email. Directing someone by phone takes 30 seconds. Writing an email usually takes much longer, and is much higher latency feedback.
Most commercial software is mind-bogglingly complicated. Many custom software projects try to emulate the design of commercial software. Both, are, I think, a collossal waste of money because the complications and frustrations in dealing with them are more expensive than the problem they address, and that the problem often has a low tech solution, or a better mixed high/low tech solution.
Prefer to print documents out because ensuring that I always have a device that can read their electronic form wherever I can take the stack of paper with me is an annoyance.
Used to have a PDA but found them to be unfulfilling.
Used to have a phone that had sophisticated features and camera but stopped caring and now look for simplest one.
I'm 24.
The reason most large projects fail at large companies is because of PHB's. The business people with very little technical knowledge are the ones who make projects fail. If I was the head of a big corporation, I would go out and find the biggest geek I could find and make him/her the CTO.
I am and have been a senior programmer at two fortune 500 companies. I have seen projects fail. The number one reason is because of non-technical people making technical decisions. We have had countless times where PHB's have mandated a product because of some savvy sales person and had nothing to do with how it would actually enhance our IT infrastructure.
Personally I think large companies should be "component oriented". They should develop most stuff in-house, yet look to third party vendors for pre-packaged components. The Java framework and the .Net framework, (both of which we use where I work) are perfect for a component market. There are tons of plug-in components you can use in Java and .Net projects to speed up development without handing the whole project over to a third party. IMO, Java has a little advantage over .Net in the component market. While they are both big and thriving, the Java market is a little larger and you can find a lot more Open Source components that can help save costs. Though both Java and .Net will not let you down for a development framework.
Does anyone remember the /. article about Walmart's IT department? They are the largest company around (much bigger the MS), and they do all development in-house. Their IT department must be a great place to work. Walmart has total control over their _own_ IT. Now I am sure Walmart buys third party products. I doubt they wrote their own operating systems, office suites or databases. However, I bet what they do is look to the third party market for components that will make their development faster while allowing them to have full control over their own IT infrastructure.
The fortune 500 company where I work is fragmented in this regard. In our IT department, we have sub-departments that work on different types of projects. Some of the departments have PHB's that just want to buy every "solution" from a third party. However, most of the time those "solutions" don't work because they don't fit in with our business practices and wind up dying or costing a lot more money to get them to work. Luckily I work for a PHB who was a former Cobol programmer (yeah, I know, I know, but at least he has knowledge of the development process). My PHB usually wants us to program our own solutions and maybe buy some third party components if they could speed up development.
I think the author of this "article" has no clue what he is talking about. He suggested that business change their business process to "fit" the third party solution. I guess he never worked at a large company. I have worked for two and the current one has 140,000 employees. It takes ages for changes to take place. It is just not practical for a large company to change their business processes. That is why, IMO, that the best approach is _custom_ in-house development with third party components to help speed up the development process.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Is what we've found the best for many purposes. The problem with custom software is that the users often don't really know what they want before they try it out, meaning many of the hours of development time working from a project description/requirements document are lost as the users realize that what looked right 'on paper' doesn't really meet their needs. The problem with off the shelf closed source software is that the users spend many hours reforming their needs to meet the limits of the software, and often have little influence on the company to get changes made. OSS off the shelf offers the benefits of being able to try a working product out before you 'buy' it to find the one that most closely meets your needs and then the ability to modify it so it really does meet your needs (and you can always do a cost v benefit to determine what areas changing practice would be more efficient than changing the software. The best OSS for this are ones with a solid modular api that allows new features to be added as modules without changing the core.
Just where does this 50 lb brain think these COTS products came from in the first place! If you can buy something that does what you need, fine. This guy is saying that everything has been written or basically, everything has been invented... so why don't we just close down the US Patent Office... we all done. Get real. Of course you shouldn't build custom word processor these days, but I can't begin to believe we're done writing useful, cost effective, software applications. The fact that there are a lot of piss poor software engineers and program/project managers out there that can't engineer or manage as well as they can dream shouldn't be a surprise. That there are government organizations like the FBI that can't either, well that's another shocker too, isn't it... NOT! Custom Software isn't the problem, and COTS isn't always the answer.
Try a simple search at http://sourceforge.net/search/ for Oracle, for instance (try LDAP, AD, 'web service' J2EE, and so on.
"He cites the example of Ford scrapping a custom built software solution for buying supplies."
... that Ford had decided to unplug its Oracle procurement system...and collapse its purchasing processes around its original custom-written, mainframe-based applications. We completed an evaluation ...and made the decision to transition back to the proven, current system, Wood said.
Umm, the Ford example scrapped and Oracle-based customization for its "original custom-written" application:
"Ford spokesman Paul Wood today confirmed
It's now Ford's intention to migrate any relevant new features from Everest to its legacy system, using in-house development staff. "
So how does this in ANY way argue FOR COTS? Duh.
I'll preface my opinion by saying it depends on the type of application, the skillset & passion of the internal developers, and most importantly: how the internal development project will be managed!
I agree with others that if the application performs a generic function, such as ordering parts, that it may be best to go with an open source or COTS solution. But custom development can work wonderfully for the unique needs your company has.
I work for the engineering department of a major telecommunications provider. Development used to be handled by individual local markets who hired their own software developers & innovated with their own software ideas. I'm talking about industry specific things and processes that differentiate us from our competitors. Many of the local developers were quite competent & produced successful apps that people used and LIKED!
Yes, this arrangement had the drawback that each market was doing things their own way and sometimes duplicating work on the same concepts. But development was quick and responded to the changing needs of the business.
Just as the developers across the country started to discover each other and coordinate their projects on their own, the company decided it was time to pull all developers under national management as an Engineering "Support" Group. The original 11 developers were added to a ridiculously large org chart of 200 people, mostly managers with various titles. Development was the tiny box at the bottom.
If they had focused & directed the efforts of the existing developers in an efficient way, they could have turned out much larger and more robust applications. Instead, our internal customers now wait as long as 2 years for an application that could have been developed in 6 months or less. The opinion of the support group is negative, and the customers are reverting to hiring local people to do development under the radar just so they can get what they need.
I think the problem is that they added too many layers of the wrong managers. First, very few of them knew much about software development when they were brought in. Second, a majority of them were brought in from outside the company and had no knowledge of how we did business. Therefore, we lost our biggest advantages.
So now the developers, who used to work in the local markets alongside the engineers and who know the business, have no influence on which projects we do or how fast we can get them done. We're a tiny cog in a large machine. And we are openly disregarded as a function they would like to outsource anyway.
Don't misunderstand. I believe we needed to have centralized management. But I often feel that if they started with the 11 of us and added only minimal extras: technical writers, testers, and a small management team, we would have magnified the effectiveness of the original eleven.
Shane
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.
...is that the only truly successful development projects are the ones which engineer the software and the processes at the same time. I've seen this first-hand several times, and have seen evidence of it in many other cases where I did not have direct access to the development effort. It really doesn't matter where the software came from (COTS, outsource, in-house, etc.), just that the processes are engineered at the same time.
Another thing I have observed in my region is that most heavily technology-using companies of 150+ employees will employ a software person on-staff (maybe with a dual role on help-desk or the like). Used properly, this is a great formula for successful projects as the in-house person can make the determination (in concert w/ the employees affected) as to how to develop the software.
So basically you just made the argument for geeks to go into managment. So why aren't you? I'm sorry (no I'm not) that the reality is that geeks are shunning managment (read calls the shots), and then whining that everyone else isn't doing what the geeks want. You all want "control"? Well there's only one way on this planet to do so, and that's work for it. Acting surprised that others are acting in their own interest is simply being naive (like you guys don't. Double naive).
whether it is Free, Open, Taxpayer funded, Private, Public, whatever. The FBI could not even do a document handling program right and Microsoft Windows is still full of bugs... ;-)
Oh well, what the hell...
Well let's see. Plugins, Macros, Clearly defined and stable APIs, proper layering and compartentalization, written in a language that's customizable. Open standards all the way. Sounds like OSS. Now all one's left with is the inertia that all FOSS faces.
Proprietary vendors will continue their assault on FOSS solutions, reason and logic be damned. They have to, their survival depends on it. How many times have we heard "Free software might be o.k. for X, but it's the wrong approach to Y."? Pure FUD. It was o.k. in the server room, but never on the desktop. Well gee, looks there's some momentum on the desktop these days ... but _wait_, the datacenter just won't work out.
Here's news: the datacenter is also under assault. Those multi-million dollar boondoggles Learjet Larry Ellison and his ilk promote are becoming increasingly difficult to justify. Don't expect them to bow out without a fight, though. They know they're in mortal danger, and they're gonna fight like hell to prop up the value of their increasingly worthless paper money.
I really have no idea what the hell this guy is talking about "off the shelf software". What? Word?! "Don't write a word processor yourself." Gee, that's a revelation. There's certainly no justification anymore for entangling yourself with proprietary bullshit, though. Datacenter apps? I've never seen one that comes in a box. They come in a whole bunch of boxes, and require an army of consultants to install, customize, and deploy. And for some reason those dang consultants just never seem to want to leave.
No really, I'm baffled. WTF is this guy talking about - "off the shelf software"?
FLEX, Laszko, XUL+JS is the future of Web apps. We may even ditch HTTP, and go with XPP (Jabber) for those who really need the response of a local app. As far as clean interfaces? Should one really be depending on limitations for doing a proper job?
In the industry I'm in (Oil and Gas), the science is evolving all the time. Many major oil companies employ PHDs to come up with new algorithms and analysis techniques to give them a competitive advantage, not only in prospect evaluation, but also in optimising recovery from the reservoir. This technology, whilst available off the shelf, is considered core business (obviously). Some packages in the marketplace just don't do exactly what the likes of (particularly) Shell, XOM etc want in some cases. Thus, they write their own. They often end up being bought and brought to market by the likes of Schlumberger, Landmark or Paradigm, but in some cases the tech started at a producer. I also found this to be the case in the financials industry. Workflows can be so different across organisations, that the one size fits all approach doesn't apply.
in house vs boxed. boxed - won't do everything you want, ever. it also has no possible chance to be modified to do what you want exactly, since it'll be closed source. it also won't be much cheaper. it's only advantage is it's done here and now. in house - you must simply hire a decent programmer/team, or you can end up with lemons.
If you mod me down, I will become more powerful than you can imagine....
If you need a time tracking application, and part of the answer is a database, then use a COTS database, and custom forms as required. No need to write your own database engine. This is an example that's come up at one of my past employers - they bought a hideously expensive all-custom time and parts tracking system that required consulting $$ to develop each access menu, and it was such a piece of sh!t that we ended up getting one of our guys that had done some database dabbling on the side to create an app with equal functionality and much less overhead (not to speak of the cost) using an SQL database and some Borland Builder front-end pieces.
Less is more.
We have been wasting millions trying to get it to work, what fun!
All the restrictiveness of COTS with all the quality and support problems of custom software, it just doesn't get any worse than this.
Rememeber, you don't really need ad hoc searching, and having a shadow system (that actually returns the data you need) running alongside your PoS "database" is good for you.
On the bright side, we now know for sure where Dilbert works!
Ellison would be doing a FAVOR to PS's poor clients if he chucked the whole thing tomorrow!
Walmart is the killer app of inhouse IT. Any industry which uses computers can and should develop a competative advantage with custom software. Any one who uses COTS software in an area where some competitive advantage could be derrived is just giving that away.
Once again the truth becomes self-evident: those that can, do; those that cannot, teach; and those that cannot do either write uninformed opinions about what the other two are doing. Carr is a clueless twit whose lack of real-world experience is painfully obvious.
The $2 billion (CAD) Canadian Gun Registry system fiasco makes the $170 million FBI software failure look like a walk in the park. ($2B CAD works out to $67 CAD for every Canadian). It's good to see the the Americans keep their government accountable to its citizens. In Canada it is the complete opposite - this type of project is commonplace - and what is even more alarming is that the Canadian voter keeps re-electing the same politicians that created this mess in the first place. A classic case of getting what you deserve.
The following text explaining the problem is an exerpt from this website:
And why were there cost overruns? "From the start of the business process and technological development of the CFP, EDS and SHL Systemhouse (subsequently acquired by EDS), responding to requirements defined by the CFP project management, performed a large number of changes (1997-319 changes; 1998-310; 1999-474; 2000-415; 2001-260; and, 2002-112) leading to a CFP technical solution that had rapidly evolved from seemingly straightforward to very complex."
In other words from the beginning the IT companies controlled the whole process, they provided the hardware, developed the software and data processing, and maintained control over it leasing it back to the government. Every time a change was made a charge was issued, driving up the operational costs of the CFC and the CFP. The costs were in the millions, and the government still did not own the hardware, software or data, this was still the property of the IT company.
And the reason these costly changes were required? "The Canadian Firearms Registration System information technology was modified several times before and after licensing and registration began in December 1998. The technology was developed in parallel with repeated changes to Program forms, rules, and processes and before legislation and regulations were finalized. The Department stated that the complexity of the system increased unnecessarily because many of the design assumptions were invalid; the system was intended to capture detailed information about firearms for criminal investigations and process licence and registration applications; however, the information needed for criminal investigations was well beyond the administrative needs of the Program; and small changes, such as modifications in data entry on a form, required major changes in the whole system because of its size and complexity, and these changes typically took three to six months to implement at a cost of millions of dollars."
So the Justice Department created a system that was not just simply about Canadian registering their guns but also an attempt to track gun ownership for police purposes. This was the underlying problem with the IT program. And they left the creation of this overly complex database to EDS and SHL Systemhouse. That system instead of being adaptable became a very expensive white elephant.
"In 2001, the Department told the Government that the three-year-old Canadian Firearms Registration System was not working well; its technology was expensive, inflexible, out-of-date, and could not be modified at a reasonable costs to support future operations. Construction and maintenance costs of the existing system were exceptionally high and without radical change, these would represent over 60 percent of future operating costs. This would be significantly higher than the industry norm of 10 percent to 20 percent."
Refer to the website above for more details.
95% of commercial off the shelf software sucks.
95% of custom developed software sucks.
I've had to deal with both, and it was very tempting to switch the other way when dealing the some of the absolute crap that gets programmed. So whoever is saying one particular kind of software is bad was probably dealing with that kind of software most recently.
The conclusion: 95% of developers (analysts, programmers, project managers) suck.
The solution: hire the other 5% regardless of whether you need something special developed in house or are developing the next greatest commercial software.
now we need to go OSS in diesel cars
is pretty lame.
The top problem happens to be planning and specification. Many of these companies, that I have worked with, are willing to pay in-house staff to solve computing problems, but are not willing to pay for the proper planning and specification process necessary to get good solutions in the end.
The result is many projects being a quick hack that get added onto until it's one big mess.
Failure to plan and properly understand their own processes hurts any software though. If these mid-sized companies decided to go with a packaged solution, it's likely they will continue the same mistakes, unless they are willing to bear the cost of changing business to match the software (at the expense of their potential competetive advantage) or are willing to let the implementation people actually do their thing, they will not see the returns the package promises.
OSS has serious potential in this area. IBM knows this and it's paying off. Success will remain elusive until the core problems of planning and specification and process understanding are solved.
Blogging because I can...
You know what? The government screws up the process of buying and implementing COTS software every bit as thoroughly as they screw up the process of building custom software.
Mr. Carr's op-ed piece notably fails to mention salient facts about the event that occasioned it. Why did the FBI cancel a $170 million electronic case-management system? "Um...because they should have bought a COTS system!"
No. If Mr. Carr troubled himself to read the NYT's article on why the project got cancelled, you can't see it from his piece. Topping the list: difficulties in getting disparate entities to come to agreements on how the sensitive information they collect should be shared.
Does this sound like a problem that could be better addressed by buying COTS software? No, it does not. And it isn't.
Does it sound like a problem that should have been resolved before, say, spending money on software? Why, yes, it does. It sounds like a mighty important stumbling block. And yet it wasn't.
This situation has nothing, not one little thing, to do with COTS-vs.-custom.
Absolutely nothing in the story of this system's cancellation surprises me, nor any of my colleagues. It's exactly like the California DMV's cancellation of its $70+ million system upgrade back in the late 1980s. Or the upcoming cancellation of their $250+ million California Case Management System for the courts. (That one may take a couple of years, but watch for it. It's coming.)
The government's process for procuring enterprise software is deeply, fundamentally broken. (I shouldn't say "the" government; my experience encompasses county, state, and federal governments in the US, as well as provincial and federal government in Canada.)
Watch carefully, for instance, to see who at the FBI is going to lose their jobs for misspending $170 million. Hm, could it be...nobody?
How can this be? How can it be nobody's fault that $170 million of your money and mine got flushed down the toilet? The answer is: it's nobody's fault because from day one the project was structured so that when it failed it wouldn't be anybody's fault.
Here, for the benefit of Mr. Carr, is the difference between the FBI buying a custom solution and the FBI buying a COTS solution: If the FBI had bought a COTS solution, they would have spent $170 million on licensing, configuration, and implementation. Then they would have cancelled the project.
I remember hearing about some next-gen health care software project at Unum. They blew $380 MILLION dollars on it, and canned it before it was anywhere close to being done.
I'd think that after the first $15 million they would have realized it was impossible for them to actually design, much less create, a cost-effective piece of software.
People citing having in house development team, but they don't cite truism, managing programmers is like herding cats. There are managers that can energize coders with storm of cheap nerd-gets, etc etc. Keep them cranking code. Most of the time COTS does look like better solution, because in hindsight custom solution looks as hard, but then you have to deal with unruly programmer. Well, to have good product you have to justify manager and at least 2 programmers. Programmers shall be happy working with small team size where they will have less of social geek life too.
I general its not that COTS is better or worse, its just managing and being responsible for team of coders is harder to absorb then having relationship with COTS over support phone line.
From perspective of PHB.
2cents of mine to you
on that crappy software and improved their cars
their competitive advantage would be ten-fold.
Why should Ford's be any worse than Mercedes, BMW, Hondas or Toyotas?
Stop building crap and starting kicking some ass.
-Nazz
COTS Salesman: "So, I'm here to show you how you can save money by firing all your developers and buying commercial off the shelf software".
In House Developer: "Fire who? What?"
CS: "If you'll look at this first powerpoint slide..."
IHD: "Woah, stop, hang on there. What was that about firing all the developers?"
CS: "Let's not get bogged down in specifics. As you can see by this diagram, by buying COTS instead of developing your own software, you can save bundles of money which you can then spend on executive compensation packages."
IHD: "Ah. I see what this is about."
CS: "Good! Glad you're on the same page. Now, I don't know what YOUR compensation package is like, but if you're like the manager at the last place I demoed this at, you'll really love this stuff. Are you ready to make some cuts?"
IHD: "You have no idea."
CS: "Excellent! So, ok, you can lease this set of packages here for a low, low price of... Ah, you have a question?"
IHD: "If I buy those packages, I own them, right? With source code? Open source?"
CS: "Uhmmm... No. They're proprietary. And really, you don't buy them, you lease them. It's all in the EULA."
IHD: "Lease them? Like with a car?"
CS: "Exactly! Like with a car!"
IHD: "Meaning that I have to send in car payments forever, but I never get to own the car, they can take it back whenever they want by claiming I broke an agreement, and if I drive too much they charge me extra and hit me with fees?"
CS: "Well, maybe not exactly like with a car..."
IHD: "How is it different?"
CS: "We don't hit you with fees if you drive too much!"
IHD: "So you admit you can take the software back whenever you want by pretending we violated the terms of an agreement."
CS: "That's not what I meant! We wouldn't do that."
IHD: "So you'll put that in writing?"
CS: "What was that?"
IHD: "You'll put it in writing that you'll never revoke our rights to the software, even if we break an agreement in your opinion?"
CS: "We can't do that!"
IHD: "Like I said, it's like a car lease."
CS: "Nevermind, let's move along."
IHD: "Not TOO far, I don't want to get hit with fees."
CS: "Very funny. Ok, in this slide, you can see how much... What now???"
IHD: "What if something goes wrong with the software?"
CS: "You call tech support."
IHD: "You mean wait on hold for six hours, and end up talking to some Indian guy who doesn't even speak English, only to have him read off a script he barely understands and end up not helping me at all?"
CS: "Yes! NO! Dammit, what's your problem?"
IHD: "I don't have the problem. Maybe you have a problem. Your pitch really sucks."
CS: "You won't let me GET to the pitch! You keep asking me these dumb questions!"
IHD: "Oh, so I'm DUMB now? You get a meeting with an exec and you call him dumb?"
CS: "I didn't mean..."
IHD: "I'm calling security. If you're not out of the building within two minutes, I'm going to have the big boiler room guy from Alabama tell you what purty lips you have."
CS: "Ok, Ok, I'm leaving..."
A minute later, out in the hall...
The Executive, Late for the Meeting: "OH, hey, Nelson... What the hell are you grinning about? Shouldn't you be debugging or something?"
IHD: "Oh... Nothing, I just had a very productive meeting, sir. I'm on my way back to my cube."
TELFTM: "Well, get a move on. Say, did you see a vendor around here somewhere?"
IHD: "The guy in the grey suit?"
TELFTM: "Yeah, that's him."
IHD: "He called up and said he couldn't make it. He says we're not worth his business, too small a fish. I asked him what he meant, and he said some disparaging things about you, sir. I took the message if you want to see it..." (hands over a post-it note).
TELFTM: "I see... Oh, well, his competitor is coming tomorrow around Noon. Always another fish in the sea! Wait - how did you know he had a grey suit?"
IHD: "Uhhhhh... He SAID so. Well, have a good day!"
TELFTM: (grumbles something unintelligible).
(LATER)
IHD: "Yes, I'm calling for Mr. Thompson, about his meeting tomorrow at 12? It's been bumped up to 11:30. Yes. No problem, I'll meet him at the door myself. Thanks, miss. Goodbye."
A developer's work is never done!
Farewell! It's been a fine buncha years!
I have never seen a real ! major COTS "customization" project either: 1. be on time for delivery 2. cost what the "big name firm" analysts said it would 3. be actually doing what was advertised 4. and finally be actually stable-serviceable-extensible at least not in 15yrs experience in designing sw for mostly for Telcos. Generally mgmnt hides behind the "COTS=less risk" factor and at the same time COMPLETELY IGNORES the tech staff's reccomendations, generally this produces far more deployement disasters than any custom development (at least in the tlc world, especially in GSM-UMTS)
The track record of incompetent managers cancelling engineering projects part way through because they're incapable of comprehending the ups and downs of the engineering process really really is that bad. It's management cancellation that causes the doom of the majority of failed software projects.
>To me the greatest strength of web-apps isn't ease of deployment. It's that is forces developers to write simple interfaces.
If you want to make crappy interfaces like the old days you can always use Flash! Everything old is new again! Again!
In my companie we have learned the hard way.
standard products are good for standard problems but nothing can beat own software if it is written by people they use it.
Basicly we moved to OSS because we could change it the way we NEED it (and feed it back). Buy software and you are stuck in the way THEY think you should run a business.
The next think is that comercial software has its own problems. Are you a large companie so you have the power to let THEM make changes ? most times not. additional they tend to drag in other COTS software (Databases etc) but its often poorly used and the burden of managing is still your own.
COTS means you have some to blame ? forget it. read the contract (or EULA) and they will show you its all your fault.
The lost of (programming) skill is the next price to pay. unfortunaly you will notice the problems only when the skills are gone and you stuck in the crap you bought not even noticing what crap it.
COTS is not a genie of the bottle, it is an easy solution for the unwarry. programming is more than using a software.
If you resuse software, you will be able to benefit from other peoples experiences. In a business case, you will be able to hire people with prior experience.
If you reivent the software, you will have to make every mistake yourself.
You may have to make changes to your organization and how you work in order to reuse software. So what? How is this different from any other tool? If you are unconfortable to adapt your organization to a changing environment, you are going to crash and burn in the marketplace anyway.
The only advantage of custom software over traditional COTS software is that you keep the control of your infrastructure within in your own organization. However, with free software you can keep control, while avoiding to reinvent the wheel.
As somebody whom works in the Aerospace industry, Commercial Off The Shelf products are getting a very bad name - why ? - Product support and reliability.
If you create a product that relies on fully commercial product, you are open to the whims of that product manufacturer, irrespective of whether it is hardware or software. Many of these products have a lifespan governed in a few years at best (and in the case of mobile phone product 6 months), but the average life of a commercial jet airliner is 25 years, and the life of a military jet is 40 years.
If the vendor calls you product obsolete, or goes bankrupt, you may have an even bigger support issue. On a commercial jet, you have to support any electrical product for the rest of its service life. You are not going to re-qualify an old unit because the software has to be updated by spending big money, and the aircraft operators aren't going to be happy with big bills because you've chosen the wrong type of software.
Also, if the vendor writes software that shows up to a have a vulnerability, it they have stopped supporting the product, you are sure going to have to pay for the support ($2 million per line of code, if you can get it of course, they might not be interested in your business anymore). Believe me, as a Component Engineer, we go to great lengths to ensure that we get still use 15 year old microprocessor families, as we are not going to get the software re-written without huge expensive.
In essence we are talking about the attitude of non-engineering people that don't see the benefits or long term cost savings of using in house software for specific applications. If they want to get on an aircraft run on Windows XP, it's up to them. I'd prefer not to have a crash due to poor product support thank you very much.
Perhaps these people should talk to people such as the Component Obsolescence Group (www.cog.org.uk), and then they might think again about their bright ideas.
Yes, I believe the COTS versus build-it discussion misses the point in some places.
Here in the UK, we are about to spend between £2.3 and £18 billion for new IT infrastructure for our health service. One of my colleagues has already pointed out that the US went to the moon for less than this. This project is already in trouble because of issues around process and user acceptance, these are not COTS vs in-house issues.
What, on earth costs this kind of money? What on earth costs $170 million? Health service IT has already abandoned a £100 million email system leaving a £10 million tip on the table.
Keep it simple stupid, with good prototypes that model processes and provide good insight to the -real- problems and benefits are often very valuable. Also, I suspect that these spending figures can be reduced by a factor of 10.
Not in the interests of Accenture, Cap-Gemini, EDS etc. though.
On y va, qui mal y pense!
The projects i have been involved in has allways used one or two 3rd part components and even though we delivered the software we were not 100% happy with the results. When we first started using them all seemed find but as we used them more and more we discovered that they did not really match our requirements. So from now on i will probably still use COTS but im going to be very careful when selecting them. I think the best way is to make a requirement list of what type of component is needed and then select one that fits those requirements best. After that it is probably best to build a prototype to test those requirements. Relying on 3rd party components is a risky bussiness but if you use them with care they can save u some money and time.
For all I know, the other 84% simply weren't budgeted correctly.
More than half of the cost overruns amounted to at least 50 percent of the original budget. Of the projects that went off schedule, almost half took more than twice as long as originally planned.
So what? What if costs and time where 10 or 100x over what was estimated? These aren't absolute numbers, they're deltas relative to some dubious baselines. The implication is that nerds suck, but maybe it's the mba's that don't know how to realistically budget software projects?
Attention zealots and haters: 00100 00100
COTS: for simple things (backups, etc), *if* it hasn't been limited (or management hasn't paid for the full version, or let support lapse), it's not bad.
For things vital to *your* core business, if you don't have the source, you *will* have disasters and losses, a few of which will cost far more than the software you paid for.
That being said, there's also the problem of PHBs - upper management who keeps changing their mind while the first release is being worked on, then gives both fuzzy specs and utterly unrealistic deadlines (unless, of course, they have live-in programmers who work 15 hours a day, every day), Then they don't want to pay for what they get - they won't hire good experienced people and managers; instead they'll hire someone with a bunch of certificates who has little RW experience, much less success.
Whose fault are so many failed in-house projects? Upper management, who never took a technical writing course, and so have no idea how to scope a project, and not ask for the moon on a dollar and time budget for an oil change.
mark
A building typically gets screwed up not because you buy bricks off the shelf or you make them yourself.
Often the actual need for such big projects is to help a big bunch of people keep their jobs and/or make a big pile of money because "something needs to be done". Even if that "need" has some real basis, the usual main consideration is how that bunch of people can keep their jobs and/or make a big pile of money.
BTW, take a look at the Iraq project... Whether it's COTS or custom, doesn't make much of a difference to the people who are getting screwed/killed.
It could make a difference on who's getting the money though. And that's probably the only difference between COTS or custom that counts for the decision makers...
Using the same software and processes as the competiation will only make a company the same as their competiation. To be really innovative these days, companies need to be able to change processes quickly. This means that their software has to change at the same speed. No longer can companies wait for "the next release" to get a new feature. Any supplier (particularly tier 1 as we are) to Ford will know that Ford has ALOT of custom software. It has taken them years to develop an integrated/cross Divisional system. They have not scrapped the legacy systems, only web-enabled them. The link to the "everest" article even shows that Ford is going back to a legacy app. I was the decision maker in my organization to decide for SAP R/3 back in 1995. It was the right decision at the time. However, these days, the COTS software can not respond to changes fast enough to support the business. It is bulky, hard to configure and costs a bundle (license as well as support costs). IF a company wants to truely leapfrog its competation then it will have to switch to software that supports its specific processes, software that can change as fast as the business changes. The way to do that is to use the open-source philosophy and methods. There are too many rules about development and use of software these days. Its time to get IT (and the business departments) back to the basics of supporting what is needed to support the customer and business partners. We have to get away from Supporting companies like Microsoft and SAP. IF they can support us then well and good.. If not, there is a better way for those with the courage to ignore the consultants and take the less traveled path.
So basically you just made the argument for geeks to go into managment. So why aren't you?
Because I do actual work. Geeks aren't "shunning" management. The reason most geeks don't go into management is because they lack the skill set needed to manage, or indeed to get the opportunity to do so. When HR is hiring for a management position, they look for business or management courses in one's degree, or previous business or management experience. The set of people who have these people management skills AND technical knowledge is extremely small. Even if a geek were to obtain a management or executive position they would soon find themselves alienated from the group if they tried to change the culture towards selecting technology based on its merits rather than the process by which it's selected now (politics, expense, who you play golf with, etc). Managers/executives who don't play the game find themselves on the bench very quickly.
Upper management finds themselves threatened by what they don't understand. In their own self-interest they will prevent people whose practical knowledge exceeds theirs from moving up the corporate ladder. Ultimately a lot of these decisions are made by the beancounters. Try as you might, it's nearly impossible to move from IT to accounting, nor would you want to.
Until the establishment finally wakes up and realizes that they CAN'T run their business without IT, these decisions will continue to be made by those least qualified to do so. IT managers and CIOs can argue until they're blue in the face in favor of one strategy or policy, and more often than not their recommendations are completely ignored. As a consequence, we have the current prevailing business computing environment: entire enterprises taken down by 30 lines of VB code, spyware infesting 95% of business machines, Microsoft holding multi-billion dollar companies virtually hostage to their bugfixes, and IT departments blamed for all of it, when their recommendations would have prevented the majority of the problems.
The situation is this:
IT: "We should do A, because if we do B, problem C will happen."
Management: "But I don't understand A, so we'll do B."
Time passes..
Management: "Problem C is happening! It's your fault! Fix it!"
IT: "It's not our fault, you ignored our advice and bought B instead of A"
Management; "You're fired."
Never underestimate the power of stupid people in large groups.
Glenn Flinchbaugh, Director of Wind River's Linux Program, will be speaking at SCALE 3x on the topic of Linux COTS Strategies. At Wind River he is responsible for coordinating product strategy, and engineering for their Linux offerings.
Glenn will discuss how the Linux COTS strategy enables telecom equipment providers to reduce costs and time on platform development and maintenance. He will detail the Linux-based COTS advantages that the end-user telecom firms realize, including greater openness and flexibility in the development tools; the greater range of architectures supported; and the appeal of open-source software availability.
SCALE will be at the LA Convention Center on February 12th and 13th, 2005. For a discounted conference pass use the promo code "NEWSP" or for a free exhibit hall pass use the promo code "FREE"
Like my car, that asian people like to call "red".
Dude, my car is red. It's not the asian people who make it red, It's the red paint, and it's not MS that makes GPL viral. It's the nature of how the license works and applies itself to anything that is intended for distribution that touches [e.g. so much as links with] code it contaminated.
Whether that's a good or bad thing and for whom is a different story altogether. GPL is wonderful, but that doesn't make it any less viral.-
Datacenter apps? I've never seen one that comes in a box.
... but _wait_, the datacenter just won't work out.
Hmmm... if "box" is synonymous with "computer," I am sure the consultant will preinstall it for you so it will "come in a box."
Proprietary vendors will continue their assault on FOSS solutions, reason and logic be damned. They have to, their survival depends on it. How many times have we heard "Free software might be o.k. for X, but it's the wrong approach to Y."? Pure FUD. It was o.k. in the server room, but never on the desktop. Well gee, looks there's some momentum on the desktop these days
Funny-- we provide open source solutions for desktop, server, datacenter, etc. No problems. A number of successful deployments (though currently our largest database deployment is our own).
LedgerSMB: Open source Accounting/ERP
Carr makes a good point about overamitious projects that attempt to manufacture a grandiose kitchen sink that are wont to fail due to ever-accreting feature requirements and neglect of how resulting growth of complexity can hamstring a project.
But, too easily does he suggest that using COTS software solutions are the way to go and that businesses can modify their business processes to fit to the software.
All businesses don't make widgets, so trying to fit them into COTS software like a Procrustean bed could ential more pain and suffering than pursuing a middle road, balancing standard COTS components that are interoperable, simple and adaptable with a small amount of customization.
"Provided by the management for your protection."
Recently I received a copy of a memo forwarded by a CIO strongly in favor of moving towards buying applications over custom building them. While I can't reprint the memo here, I can speak to some of the points it made and respond to them from an alternate perspective. The memo summarizes one case study within the company of what is portrayed as a successful acquisition and implementation. The application is based on a vendor product and customized in-house to a limited extent. The case study asserts the benefits of the buy decision over three areas -- the technology, the cost, and quality.
In the memo, the author says that a system used by the business is based on a commercial application and claims 90% of it is standard and 10% is customized. There's no detail to justify that number, but suppose the software does 90% of what the customer needs. Left unmentioned in the memo is how much of the application is useful to the customer. In other words, what additional features and complexity is the business paying for with the application suite but not using? It's unlikely that 100% of the features of a commercial application are used by any one customer -- but can the business say it is using even 50% of them? Is that cost effective?
While the vendor's support may help keep the business current with technology, how much are the vendor updates just a way to keep the upgrade treadmill running? How often does the vendor introduce an update where none of the new or changed functionality is useful to the business? What is the cost of being on the vendor's development schedule, and how disruptive are upgrades? Worst of all, what happens when the vendor eliminates a feature that is key to the business?
The memo asserts that there is a significant cost savings to purchasing vendor-supported applications, because the costs of development are spread across all the customers. That's a bold assertion, but looking closer, to what extent is that cost savings eroded by the additional cost of features which are developed but not used in the business? Is the total cost of the software, including those elements useful to the business and those that are not, really less than a solution tailored to the business?
Typically, vendor-supplied software includes install and configuration wizards and GUIs that are more extensive and more polished than what is developed for in-house software. This is driven by the need for customer to be able to implement the system without in-depth expertise. While there is certainly value in those kinds of features, are they worth the additional cost? They are primarily an example of the kind of additional development done that is not directly attributable to customer business needs. If those features are of value to the business, why doesn't the in-house development process reflect that value? If the purchased software is perceived as better-tested and more robust than in-house developed software, those cost of those aspects is surely included somewhere in the purchase and support price. Again, if these aspects are valuable enough to enter into the purchase decision, why doesn't the in-house development reflect this value?
All but the simplest COTS software will need customization. While is impossible to accurate assess how much, it is possible to determine what portion of in-house resources go towards needed customizations versus integration with other systems. If the integration is complex and problematic it can take time and expertise away from providing business-critical customization. If the users go without their needs addressed because everyone with any expertise is struggling to make the software talk to the rest of the systems, where is the value in that?
A critical aspect of vendor application customizability is a powerful, well-documented, flexible and stable set of APIs that allow the customer to modify the behavior of the software without introducing incompatibilities and dependencies that cause problems in later upgrades. The question to as
I realised the problem with this article is that it is actually wrong.
We want to use off the shelf solutions that are best for our business (or person) whether they are commercial or not. I believe that CPAN is the best off the shelf solutions available today in a clear easily searchable fashion. I want to use this because it is good software (mostly) and it works. It is not commercial so it is not COTS.
Declare war on the COTS phrase, it it OTS!