What are pros and cons of using “in-house” tools? [closed]

Question

What are pros and cons of using "in-house" tools, from real-world experience?

Answer 1

Pros:

• customizable without limit
• because of its limitations, may provide a consistent look and feel for all application developed with it

Cons:

• often: lack of documentation
• becomes obsolete soon, because the rest of the industry just works faster
• probably more buggy than a similar tool used by millions of users
• no users outside the company - forget about asking stackoverflow etc.

Answer 2

Pros:

• does exactly what your company needs
• can use bleeding edge technologies where there is no market alternative
• bugs can be fixed by the author according to management priorities
• lack of documentation made up for by access to author (also cf FOSS products)
• can become a product in its own right

Cons

• does only as much as your company is willing to pay for
• suffers from all the same problems as your other in-house software and has to compete with that for resources
• no outside community support

Where this has worked well for companies I've worked for has been the bleeding edge stuff. If the underlying technology is only just arriving in the market, your in-house layer on top of that or component that uses it probably has no alternative. If it works well you gain a huge advantage over your competitors (if any). In this case the question is whether you release it as a product or wait for the market to catch up. Either can be valid choices.

If you're just using an in-house alternative to existing products you're probably doing it wrong. The best case is that your team delegates someone to contribute to a FOSS offering to drive it in the direction your company needs. The more usual case is that your team reproduces something they could buy, but in a more expensive way with more bugs.

Answer 3

I'll take an example from an experience I've had recently.

Having someone in-house to provide a suite of UI controls for the company, just to make them feel like they have a company branded suite of colours etc.

Pro for this is having complete access to the source code, someone having built the framework knows it so they can implement changes/bug fixes in a quick amount of time.

Cons are, there was no-one in house that was skilled enough to build the user controls so bug free and to the correct standards that a company dedicated to writing user controls would. The company felt ok about this, because hey, we find a bug, we fix it on our own time. Buying that UI control tool-kit for $1000 is just "silly when we can do it ourselves".

So sure, I use the API, to find tons of memory leaks and problems, which in the end I can say I've spent days fixing and fiddling with. And as a contractor, it certainly amounted way up over that $1000 they didn't want to pay for a professional UI toolkit. This really didn't make sense to me.

I've kind of come to realize over time that a company that says we must build everything in house is a little foolish. Sure you feel comfortable in having control, but that certainly isn't the best decision. There are public API's or other companies that WILL save you time and money in the long run, ultimately making you more productive.

Answer 4

I'll just prefix this by saying that I only think it's ever valid to develop in-house tools for your core competency. That is, I would never ever develop an in-house source-control system, because that's not my company's core competency. Nor would I develop an in-house build-system, etc. However, a web development company might build a custom UI library or a custom Ajax library, if that's part of their core competency. A software company that provides email solutions might build their own SMTP server in order to differentiate themselves in the market and so on.

In my experience, the way this has usually worked is we've evaluated the options out there from 3rd parties, and chosen the best one that seems to do 90% of what we need right now. We'll use the library for a while, get to know it's quirks and limitations and only then do we start to evaluate whether in-house is worth-while.

Often-times, it's actually more efficient to continue working within the limitations of the 3rd-party library than to develop in-house. Because we've actually been using the library for a while, we know exactly what it is required to do, and what it does for us, so we have a pretty good idea of what it would take to re-implement all of that.

On the other hand, there have been times where scrapping the 3rd-party library and writing our own from scratch as hugely benefited us (in terms of better performance, fewer bugs, etc). But I think this is only possible after you understand the problem domain intimately well, and that's only possible after actually deploying and supporting your solution for a while.

Obviously, this doesn't work in all situations. But I would be very careful about skipping the "evaluation" step, since that would be a pretty big red flag that someone is just making an emotional decision and not a rational one...

Answer 5

About fifteen years ago, I worked for a company that had its own version of COBOL, implemented with an interpreter written in C. It also had its own display API and file API. The separation was the only good thing about it: it meant that we could ditch the actual front end and back end code provided we wrote a compatibility layer to a database and a decent third-party display. At that point, it might be possible to write some documentation. I dug around in the C code, and it looked like a really big job.

In the meantime, we were stuck with a badly documented version of COBOL, and didn't know what we could and couldn't use. We kept seeing neat stuff for COBOL programmers that we simply couldn't use, and there was no hope of upgrading to a better version of the language. It turned out that the code we had was sufficiently nonstandard that it was impractical to convert it. There was simply nowhere to go: the company would be stuck with primitive tools until the code base got a major rewrite. This led to programmer dissatisfaction, as the more competent and creative employees got increasingly frustrated by the increasingly outdated environment.

I left the company before there was any resolution to these issues, and when I checked up on it next found it had been bought by another company and all facilities removed from my metro area.

I've been on other projects where the cost of my time considerably exceeded the cost of buying a third-party tool to do essentially the same thing, only with better support.

This left me with a firm opinion that third-party software tools are normally cheaper and better than in-house. (This does not apply to third-party custom software; when I worked with such third parties, I wound up dividing the software into "inhouse" and "outhouse".) Write what you need to write because there isn't anything available, and try to stay flexible so you can move to something third-party. Write what makes the business special. Try your best to buy what helps make the software that makes the business special.

Answer 6

Please include open-source in the places I mention commercial.

While I prefer to use open-source or commercial products when available, I have had cases where the tools just weren't available. In those cases, I developed in-house tools. The concepts of one of the tools was later commercialized by the vendor.

Pros

• From the management side, programmers tend to be treated as sunk costs. Therefore, in-house tools don't appear to cost anything.
• The tools don't need to go through the purchasing process. (Ever tried to get an invoiced for an open-source product.)
• Minimizes delays for feature requests.
• Ability to have and use tools which aren' yet available elsewhere.
• Even fully costed, they may be less expensive than the commercial product.
• Tools may fit the environment better than commercial tool.
• May be able to commercialize the tool.
• It may be easier to update the tools to meet ongoing changes in requirements.

Cons

• Limited support. There may be only one team member who knows the tool source.
• There may be more important tasks for the programmers to be working on. Just because the programmers are already there doesn't make them free. (Unless you get them to work unpaid overtime.)
• Maintenance is not likely to be a high priority.
• Less likely to follow standards and best practices.

Answer 7

The more I am personally involved the better. If I design it or make a request to someone else and tell them how I want to use it, there really shouldn't be any learning curve. Buy someone else's and you have to learn how to implement.

Answer 8

Pros: You control it. You can fix it when you find a bug.

Cons: Unless it the core competency of the company, and so potentially a marketable product, it's costly. For instance, if a company pays it's engineers $100k a year, that's about $50 an hour. If it takes you two weeks to make the tool, it cost $4000, plus whatever time is spent maintaining it. Think about what sort of systems you could make in two weeks. Are they worth $4000?

Additionally, a vendor specializing in the tool is going to have more that just you as a customer generally, and so the level of polish and usability will potentially be far higher than you can afford to put into the tool. They are counting on making their money in volume, and so can afford to spend far more time on making the product good.

Of course, all bets are off if the available tools are so poor that you have to have a person dedicated to maintaining your installation of the thing. Then it might be better to roll your own. And market it. :)

Answer 9

I've worked on both an inhouse-developed trading system and a trading-system bought by a third party. In my experience it boils down to control vs flexibility.

If your inhouse-trading system has a bug or you don't know how something i calculated or why, you look at the source code. How bad it may be (and i can tell you, it can be very bad), you always get an answer. With the thirtd-party app, you are dependent on the supplier.

If you need to develop some features and lack the man power, with the 3rd party app you just hire some consultants. With the inhouse app, it's more difficult to get support.

About costs: for this special example the 3rd party app and the consultants are very expsneive. I really doubt, that it is cheaper.

Answer 10

Every time I have seen a software development shop develop in-house instead of a using a popular external technology, it has been a huge mistake. In the 90's I worked for a company that decided that the then popular Rogue Wave C++ object library would not meet their needs, so they wrote their own. The complexity of the task was greatly underestimated, and the resulting library was a maintenance nightmare, and ended up costing at least a quarter million dollars in engineering time. They also decided to build their own customization language, instead of integrating with an existing scripting language like Perl or TCL. The proprietary language was buggy, poorly documented, and difficult to use. In the end, this was a multimillion dollar mistake.

Avoid writing new solutions to common problem like OR mapping, scripting, etc. unless no existing solution will allow you to get to a deliverable product. If there is an existing public domain solution, consider enhancing it rather than starting from scratch. There is no way an internal software group can outproduce the entire open-source community.