[tabtab]

Re: Any code you re-invent is code you have to maintain.

But the flip side is that any code you borrow you have to fix, debug, and/or replace if it doesn't work as intended. I personally find it far easier to fix my own code than others' code.

I'm not claiming one should reinvent most wheels to gain control, though, only that there are trade-offs for each. If you borrow code, you should have an alternative(s) in mind if it stops working in the future or key bugs are found in it.

For example, using a JavaScript date-picker gizmo for forms is usually not a big maintenance risk because there are multiple to choose from. If you had only one choice and that choice went kaflooey, then you'd be stuck.

Well, the user could hand-enter dates. For internal software that's an acceptable temporary work-around, but not for commercial software, because every customer expects a date-picker (and the HTML5 ones currently stink if you want mm/dd/yyyy formats).

In short, don't heavily depend on any external part you don't have a "Plan B" for.

[RealDinosaur]

> I personally find it far easier to fix my own code than others' code.

This is a problem with larger teams though if anyone else needs to work on the code, and results in code that doesn't have documentation/support available.

Not documentation as in 'He didn't make a confluence' page, but documentation as in 'If I google this error message will I get a good answer'

[tabtab]

I'm not sure what your googling-error-message example is intended to demonstrate. And again I'm not claiming self-rolled is always better; but merely responding to a specific claim. The bottom line is one has to weigh the trade-offs using multiple metrics and factors. A large part of managing technical projects is the balancing of tradeoffs.

IF an app depends heavily on a feature AND there are not many external alternatives, then a shop should lean toward rolling their own.

A related issue is the volume of code. If the in-house version is 500 lines of code and the external (downloaded) version is 5,000 lines, then the internal one may be easier to debug and fix. (Yes, I realize that lines of code is not the only factor to consider.)

Common factors to look at:

1. Complexity of the part, including dependencies on other parts.

2. Swappability of the part for alternatives.

3. How well the part is written and documented.

4. Need for the part. If it's merely a "bonus", then dependency may be less of a problem/risk.

[jakelazaroff]

If you use an external library, it's much more likely that you can google any issues you have with it, rather than having to reverse engineer it. The reason the GP quoted this:

> I personally find it far easier to fix my own code than others' code.

is that if you work on a team, you're fixing others' code either way. The difference is that with an external library there's usually documentation, a community, etc; but with a home-rolled solution, you're usually on your own.

[tabtab]

External libraries usually have to cater to wider usage and thus have more code and more parts and more options. A "dedicated" in-house module will typically be much less code because it has one job, meaning less to read, reverse engineer, test, etc. I'm not saying one is always better than the other, only that one brings in a rather complex wad of code in most external libraries that could be a bottleneck.

The "community" often ignores my bug fix requests, I would note. Maybe I ask wrong, but we don't all have wonderful asking skills. If you do, that's a nice feature of your personality, but doesn't necessarily extrapolate to all code users.