

We Are Abstracting on the Shoulders of Giants - dmsimpkins
http://www.hanselman.com/blog/WeAreAbstractingOnTheShouldersOfGiants.aspx

======
chokma
A good way of finding your own giants is trying to comply with all licenses
your own software depends on.

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](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](http://cinnamon-
cms.com/de/standard/riesen-und-zwerge)

edit: clarification / fix typo

~~~
shanselman
I love this. Great point. The dependency chain is huge.

------
snarfy
> I generally understand the full stack from assembler all the way up to
> managed code and beyond to the cloud.

Please let this be the new definition of 'full stack developer'. I cannot
stand the current definition.

~~~
falcolas
Let me get this clear in my head - you want "Full Stack Developer" to be
someone well versed in everything that is happening from the assembly running
on your machine to the browser, to the network stack and routers, down to the
server, and back down to the assembly running on that server?

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.

~~~
snarfy
No, not really. Even Hanselman does not say he's well versed. It's a general
understanding. I wouldn't expect a full stack developer to be able to whip out
a GUI app using nothing but assembly during an interview, but I would expect
them to understand that missed branch predictions thrash the instruction
cache, what object files are and how a linker works, what a normalized
database schema looks like, basic ipv4 networking etc. These are all wide
swathes of knowledge. If someone claims they are 'full stack', what stack are
they talking about? Serving web pages? If that's all it is, wouldn't 'web
developer' suffice?

"The full stack developer brings the SaaS cloud to you with webscale!"

It even sounds like marketing garbage.

------
falcolas
All that abstraction has a cost. Additional compute time (and energy) to work
through the abstraction layers. Having to debug someone else's code when it
doesn't "just work". Having to re-write the abstraction layer when your work
no longer fit within the defined parameters of the abstraction.

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.

~~~
delluminatus
How is having to re-write the abstraction layer a "cost of abstraction"? That
is work that you would have had to do _anyway_.

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.

~~~
falcolas
> How is having to re-write the abstraction layer a "cost of abstraction"?

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.

