Reasons not to code a program?

Let's play the devil's advocate: what would be the reasons you would give management NOT to code a solution, but purchasing an expensive package?

From stackoverflow

• Simple; BUY when the Total Cost of Ownership (TCO) for writing your own is greater than the TCO of the package. (How you reliably work out the TCO of writing your own is an exercise left for the reader ;-) )

  Not-so-simple; DIY when the software is your core business, or when the software is a unique selling point. You don't want to outsource your brain or your heart.

  Bob Cross : For those that don't know - you should define TCO at least once.

  Ed Guiness : updated with link

• A very similar program exists already. Unless you're doinng it for fun / learning purposes

• 1. Cheaper to buy in.
  2. If the domain is unfamiliar to the existing developers
  3. If the level of risk is unacceptably high
  4. Time criticality.

  Though at the end of the day everything boils down, in one way or another, to point 1.

  Gamecat : And even if 4 out of 4 apply... (sigh)

  : An addendum to 1. It could possibly also include support, which means you won't have to spend company resources fixing it after delivery either.

  Charles Bretana : Last point says it all... convince them it's cheaper... How to do that, of course, there's the rub...

• Money Money Money

  0xA3 : In a rich man's world only.

  : (-1) You spend money either way. Your answer is not clear.

• The cost and time involved in developing the new solution is high, compared to the cost and time involved in buying the solution. Usually management is very sensitive to these two factors.

• It will be cheaper, but only if you are prepared to modify your business practices to fit in with the way the package works. Performing loads of customisation on the package to fit your business practices almost always ends up costing more than creating a custom app from scratch, and often ends in tears.

• Advantages to buy a component: - It might be cheaper to buy it than to develop it - (in some case) the team doesn't have the knowhow to develop that component. So the time to gather that knowhow is prohibitive - Maintenance costs transfered to the supplier

  Disadvantage - No control of the lifecycle of the component (including when new releases are made, what fixes should be done, etc.) - It may require adaptation/integration effort. - It may introduce performance penalities due to integration issues.

• There are a lot of reasons to buy in software. In my opinion the most important are:

  • Lack of knowledge and expertise within the organization
  • The lack of manpower to quickly adapt to changes in market or law (taxation)

  Advantages of Outsourcing:

  • More easy to budget
  • No need to hire, train personnel
  • Ability to have tight Service Level Contracts

• I've seen quite a few instances of this, and I think it seperates into two halves. Firstly, there's your "commodity" software - messaging middleware, databases, etc., - that typically is always bought in. I would never sit down and write my own asynchronous messaging system, unless that was absolutely core to my business. Secondly, there is the value-added portion, which I think is rather different.

  I work in finance, and there are a few vendor systems (examples are Murex, Summit and Sophis) that perform risk/booking/back-office functionality for various financial market products. I think that choosing these is dangerous, for two reasons.

  First reason is that you are no further ahead of your competitors in terms of software, you're adding no value of your own, so it just becomes a "race to the bottom" in terms of what price you can charge, or how much risk you can take.

  Second reason, and more important from a software developer's point of view, although the vendor's system might suit you now, it may not suit you in two or three years time. If you've built your business on top of it, and suddenly it changes - or doesn't change when you need it to - you can be left high and dry. Or, if the company goes bankrupt or wants to move out of the market, you've got two options - buy it, or re-write all of your systems from scratch.

  I have lost count of the number of firms I've seen who are desperately trying to switch off value-add vendor systems (typical examples are Murex, Sophis, Summit...see above :) and write their own.

  A supplementary argument against vendor systems for value-add is that the consultants/contractors are typically a lot more expensive. A senior c# consultant can be had here for £x00 a day. A consultant with vendor system experience will be around 20-25% more.

• If you were to build your own car from scratch, it would probably be very expensive and quite unrealiable, but if you were to buy a ready made car, it'd probably be a lot cheaper and be a lot more realiable.

  The same is true of software (most of the time), every bit of bespoke code needs to not only be developed, but also tested and supported. If you can fit a product into the client's requirements it can generally be a more cost effective solution. However, I think problems occur when a product is shoe horned into a set of requirments which demand something which it wasn't designed for.

• Some reasons

  • The solution does not support a core business process, but a commodity process such as Finance, HR, Facilities management, where you are no different from your competitors (your core/noncore processes will vary!). Your internal development skills would be better used to create and maintain solutions that give your company a competitive edge.
  • The former applies in spades if the solution does not need to be heavily integrated with your existing or future solutions (it supports a relatively isolated process).
  • No need to budget and staff for maintenance throughout the lifecycle of an in-house developed application. The numbers vary, but one figure I've seen and find quite believable is that the initial development costs of a custom application accounts for only one-tenth the total lifecycle cost. Granted, that includes stuff like end-user training, O/S upgrades and integration which also hits an externally procured solution, but a 10x factor on the initial price tag will make most management take pause.
  • A special case of the former: skills for development, maintenance and operations may be lacking or a bottleneck in your organization. Every skill shortage can be filled with enough time and money, but not necessarily within acceptable boundaries. Every additional technology skill your staff needs to acquire means less time to develop and maintain existing skills: the skills cost of a diverse technical landscape grows at a more than linear rate...
  • As e.g. Peter states: predictable but high costs can trump the risks of starting a development project, in a business where 20% cost overrun is often considered a successful project, whereas unsuccessful projects have basically no limit...
  • As vatine also notices: commercial software can be had now, delayed only by installation and end user training. Granted, installation of something like SAP isn't done in a day...

  This applies if your vendor is reasonably stable. If they are small or have weak finances, commercial software can be a much greater gamble than in-house development.

  Whatever way you go, you get lock-in effects. It's never free and seldom cheap to migrate away from an application that actually finds use.

• A one-shot in-house development can be justified to replace subscription software, i.e., a one-off development cost of 2X can be justified to replace a yearly subscription of X, if you have the development resource available. It can also mean that the final solution is exactly targeted at the business needs, whereas a third party solution might not match exactly or require extra support or workarounds. This applies to projects that I have worked on in the past year or two, with a benefit that the new system is more accurate and hence led to a requirement for fewer support people. Yes, good software makes people redundant.

  In-house development should also be done for core company software, the software that allows you to exist as an entity so that you are not hung out to dry the next time your software support contract or subscription comes around, or by a solution that isn't perfectly suited to your needs.

  However one-off costs for essential software that isn't providing a core function is easy to justify, whether it is a vast amount of money for Oracle, to a decent CMS, CRM or customer ticketing system that you need by last week.

  Pontus Gagge : Unfortunately, one-off costs don't exist. You always have subsequent support and maintenance costs, whether they are visible or not.

  JeeBee : Yes, but the external company support/maintenance costs are far costlier unless you have an internal IT bidding/billing setup (because they were tired of being called a cost centre). In this case you can simply ignore the ongoing costs because the major cost is the recurring subscription fee.

• Vastly simplified, but select the smallest of:

  • For a home-brewn tool: cost = (task_execution_time * uses * $/user-h + tool_development_time * $/dev-h
  • For a purchased tool: cost = task_execution_time * uses * $/user-h + tool_purchase_price
  • Without a tool: cost = task_execution_time * uses * $/user-h

  cost is the cost of performing the task uses number of times. task_execution_time is the (person-)time it takes to perform the task including any overhead, tool_development_time is the time it takes to develop the tool.

  I'm leaving out a lot of variables to keep it simple. Add more to suit :)

• I'd give them the true reasons (assuming I was in a company I actually wanted to work for, that is, rather than having been enslaved by PHBs). Usually this is "I'll get my job done faster if I have this, and my time is worth a lot to you".

  But being more helpful: if the question is, "when do situations arise where you want to pay for software?", then:

  • When the software in question isn't the core competence out of which the company makes its money. In the case of non-software companies, then the same thing but with "department" instead of "company" and "justifies its existence" instead of "makes its money". So we're going to get a package in, the question is whether to get the expensive one.

  IN WHICH CASE

  • When no good free option exists, or where the expensive software is better than the free due to better features, lower TCO (on account of not having to fix the bugs yourself), or whatever.

  Alternatively:

  • When the package isn't just software, it's a hosted service, and the cost to the organisation of training someone to install the service and keeping a whole person on-call 24/7 to maintain it would be even more than the "expensive" package. This is another part of TCO, but it applies even if the software itself costs the same either way.

  What the first point means, is that games companies shouldn't be writing their own IDEs, web app companies shouldn't be writing their own compilers, banking software departments shouldn't be writing office applications, etc, unless you really think that you're better off doing that than writing games, or web apps, or trading software, or whatever you have actual deadlines on. Obviously there are some exceptions: if you want a tiny little script or webapp it may be easier just to write it than to find something off the shelf that does what you need.

  In the second point, "better" means different things to different organisations. Assuming equal functionality, if your department is full of linux geeks then the free option probably has more plus-points than if you have no linux geeks, and also need an SLA on the package in question. If the "package" is going to be compiled into your non-free product, as opposed to just supporting your development, then obviously free-as-in-GPL software is useless to you whereas free-as-in-MIT would probably be fine. And so on.

• It would depend in part on what management wants the developers to code.

  If it's a game development company and they're rolling their own email solution, that would be a waste. Talented game developers coding their own SMTP client and server system rather than doing much more enjoyable game development (not to mention that this would probably go against whatever semblance of a "mission statement" the developers might have had in mind when they got hired on).

  If instead it's coding some small utility or other it could be worthwhile. If there are interns, that could be a good project to throw to them to start on, or if some of the developers get sick and tired of game physics and want to do something more bland, they could work on it for a while.

• When I wanted to code something myself and my old boss thought we should buy it, he'd say, "buy the best, make the rest."

  Another rule of thumb: when it's one of your business's core offerings, do it yourself. If it's not, consider outsourcing or purchasing from someone where that is there core offering. They'll do it better anyway.

• I think an analogy would be suiting.

  Let's say you have an idea for the newest race car engine that will instantly make any car go 20 mph faster. You were able to do this because you understand intimately and at the quantum level how to optimize engines so that they work better. However, your engineering skills in other areas, such as designing a frame or wheels, is just average. Are you going to spend your time trying to improve these skills and reinvent the wheel (or frame as it were?)? No.

  Instead, you're going to team up with someone who makes the best tires and someone who makes the best frames and combine your engine with them. This saves you time and money since you're focusing on your product, not providing supporting infrastructure.

  This also applies to software. If tools you need are very complex, get them from somewhere else, because you want to focus on making your final product, not the infrastructure to allow you to make the product.