We Are Abstracting on the Shoulders of Giants
hanselman.com
hanselman.com
When writing a LGPL licensed CMS server, I tried to find all sub-projects to make sure we could distribute the software safely. Sadly, not every framework and plugin does list its own dependencies correctly - often you will find components in the lib/ folder that require specific attribution with the author's name if the software is to be used legally.
http://cinnamon-cms.com/de/cinnamon-server/lizenz-ubersicht
And for a list of Giants and Dwarves:
http://cinnamon-cms.com/de/standard/riesen-und-zwerge
edit: clarification / fix typo
Please let this be the new definition of 'full stack developer'. I cannot stand the current definition.
It would be a good interview question; it would filter out a lot of bullshit because, frankly, anybody who says they understand that for all permutations of those components is a liar.
There are very few people who would be able to even give you a 10,000 foot view of all the components that make up the delivery of a web page from end to end, let alone truly understanding all of them.
To borrow from the article - there's too many abstractions.
"The full stack developer brings the SaaS cloud to you with webscale!"
It even sounds like marketing garbage.
Frequently, the benefits of developer productivity outweigh these costs, but when an abstraction falls apart, it has a tendency of doing so spectacularly.
I tend to think of abstractions like those mentioned in the article as land mines full of technical debt. At first, it's easy to avoid stepping on them. But eventually you will step on that landline (perhaps even intentionally), and when it does, your productivity is going to suffer severely.
The analogy fits in one other way: the cost of clearing those abstraction land mines is disproportionate to the cost of putting them in your code in the first place.
I think the "land mine" metaphor is unnecessarily disparaging. Abstractions are more like roads. They make life easier, as long as you can stay on them. But if you have to go off the road, you're going to have to make a road for yourself.
Generally speaking, roads only reduce the amount of work you have to do to travel, unless you use them inappropriately (like going too far out of your way when you could have taken a shortcut). On the other hand, land mines only increase the difficulty of traveling.
Because in my experience, it's never as clean cut as "this abstraction doesn't work, lets go re-write it". The process typically goes more like:
* Identify that there's a problem, start trying to understand the code in the abstraction in order to identify the problem.
* Fork the abstraction code and make changes to it.
* Attempt to push changes upstream because "if I have the problem, other people have the problem as well", plus all the work that comes with pushing changes upstream.
* Repeat the previous three steps for a period of time ranging from months to years
* Find another implementation of the abstraction and repeat the previous four steps again.
* Finally give up and then re-write the whole abstraction in a way which actually works for your needs.
Land mines are also a leaky abstraction of the facilitation of forward movement as you have pointed out, but I have a hard time getting the "technical debt explosion in potentia" out of my mind.