

How to actually ship software that actually works - blakegardner
https://medium.com/@thomasfuchs/how-to-actually-ship-software-that-actually-works-cf269f6578f7

======
mikekchar
I think the "Coding > Configuration" is quite insightful. Admittedly I like
writing code (which is a useful trait as a programmer...). There are some
advantages to using libraries and frameworks:

\- You don't have to write the code (obviously)

\- Popular packages are likely to be free of the more obvious bugs since many
people have already used it.

\- If you have a common problem, someone probably has a ready made solution on
StackOverflow

\- You can hire people who already know the library/framework so training time
is reduced.

\- You can often avoid learning anything about how the library works and only
pay attention to the API (saving learning time). Probably more importantly,
there are some things you should _not_ write yourself because you are almost
guaranteed to get it wrong the first few times(dates and timezones,
encryption, etc, etc).

But there are advantages to writing your own too:

\- Because you only have to solve your problem and not the problems of 2
million other users, your solution can often be an order of magnitude smaller.
Less code, less bugs, more flexibility.

\- The solution can be tailored to your problem exactly. Often you need to
work around design decisions made in the original library (this is especially
true of frameworks). These work arounds tend to breed other work arounds as
each one creates undesirable code. Sometimes the use of a library that is
close, but not quite what you want results in so much disruption to your
design that you would have written less code had you not used the library.

\- You don't have to deal with political problems with people you have never
met. Often maintainers make strange decisions which they refuse change,
leaving you out in the cold. You often have nothing but a passing relationship
(at best) with the maintainer, so it is often next to impossible (and
incredibly time consuming) to negotiate design choices, bug fixes, etc going
forward. This is especially true if package X depends on package Y, but the
maintainer of package Y has significant personality disorders. Trying to track
down all the dependencies of package X and identifying possible risks can be
quite difficult.

\- Being forced to know how everything works can often bring significant
benefits down the road. This is especially true for security issues.

Clearly I don't avoid libraries and frameworks entirely. That's cutting off
your nose to spite your face. However, when evaluating libraries, I usually
favour writing my own unless there is a popular, well supported library that
does exactly what I want and very little more. Or if it is one of those things
that you should not write yourself because you will certainly get it wrong.

~~~
madrobby
Hey, I'm Thomas, the author of the article. I do agree with your observations
pretty much entirely.

I'm mostly talking about the "throw a component, library or jQuery plugin at
everything" sort of mentality. That just yields and unmaintainable buggy
mess—unfortunately I've encountered this all too often in the wild. (While I
was a consultant, I could make a good living from cleaning up these messes, so
I won't complain too much!)

It all boils down to, however, a willingness to actually think about the
things you're doing, and trying to do good solid work. IMO not enough people
do that, or even aspire to do that, which makes me a bit sad about "my"
profession.

