

Frameworks and Frankenstein - FollowSteph3
http://thecodist.com/article/frameworks_and_frankenstein

======
al2o3cr
"Sometimes it might be abandoned and now you have to maintain it yourself when
OS versions change or other needs appear."

As opposed to rolling your own everything, where you have to... maintain it
yourself when OS versions change or other needs appear.

~~~
falcolas
The cognitive cost of maintaining software you designed and wrote is typically
much lower than maintaining software which was cleverly written by someone
else.

~~~
userbinator
This is particularly true when the actual amount of functionality of some
library being used is a tiny fraction of what it has. I've rewritten a few
applications that appeared to be designed with "use as many libraries as
possible" as a goal, and it usually turns out that many of them could be
replaced with not more than a few dozen lines of code. Simple is good. The
less code in your application, the less there is to go wrong --- it seems a
lot of developers don't realise that library/framework code can also be a
source of bugs since it gets executed too, and when something goes wrong in
that code they didn't write, are not willing to trace into it to figure out
where the problem is.

I'm not advocating doing _everything_ from scratch (by that definition you
would probably need to manufacture your own hardware...) but there's clearly a
difference between depending on some libraries/frameworks that are stable and
well-used (e.g. OS, libc, JVM) and pulling in every library you can find that
offers a piece of the functionality you want.

~~~
cordite
An app that a group of mine bought license to shared that philosophy. The
source by the third party hardly works, and it the latest update wouldn't even
compile because there were over 65536 (2^16) functions or symbols.

------
buckbova
Most professionals in this field act as developers and not necessarily
engineers. Meaning, their expertise lies in assembling a system out of app
servers, frameworks, etc and are not accustomed to building any individual
piece from scratch. And in nearly all cases this is what they are hired to do,
use well known technologies to solve a problem.

It is up to the architect of any system to choose these technologies wisely. I
tend to favor extensibility and degree of coupling in my design decision which
can lead to an over engineered complex solution. However, I rarely regret
doing so. The time upfront pays off when changes are requested.

