We Are Abstracting on the Shoulders of Giants
hanselman.com
We Are Abstracting on the Shoulders of Giants
1–10 of 12 posts
Re: We Are Abstracting on the Shoulders of Giants
#2All 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.
Re: We Are Abstracting on the Shoulders of Giants
#3> 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.
Re: We Are Abstracting on the Shoulders of Giants
#4All 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 tenden…
[deleted]
Re: We Are Abstracting on the Shoulders of Giants
#5The biggest shock for me in coming back to the C# world was all the dependency injection and LINQ stuff I had to learn. The code I'm working on makes such heavy use of DI (Ninject) that I'm wondering if it's good design with all the magic that's happening. And with Asp.Net I'm using the latest and greatest web api which has it's own "best practices" for returning results and handling errors. I swear it changes each year.
Re: We Are Abstracting on the Shoulders of Giants
#6> 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.
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.
Re: We Are Abstracting on the Shoulders of Giants
#7All 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 tenden…
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.
Re: We Are Abstracting on the Shoulders of Giants
#8A 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
And for a list of Giants and Dwarves:
http://cinnamon-cms.com/de/standard/riesen-und-zwerge
edit: clarification / fix typo
Re: We Are Abstracting on the Shoulders of Giants
#9All 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 tenden…
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…
> 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.
Re: We Are Abstracting on the Shoulders of Giants
#10A 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 nam…
I love this. Great point. The dependency chain is huge.