Comments on: the tension between transparency and abstraction http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/ Mon, 16 Jan 2012 02:27:45 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Design manager http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-20 Design manager Fri, 09 Nov 2007 15:43:51 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-20 I think that balance depends on the audience, if customers are clever in subject matter then you can pay more attention to abstraction. I think that balance depends on the audience, if customers are clever in subject matter then you can pay more attention to abstraction.

]]> By: floating point http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-19 floating point Sat, 03 Mar 2007 01:39:11 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-19 <strong>A critique of Spring...</strong> If you read my blog, you know I'm not a big fan of the Spring framework. Googling around you find very little articles and posts criticizing Spring. Most notable is Crazy Bob's I Don't Get Spring weblog. My blogs on... A critique of Spring…

If you read my blog, you know I’m not a big fan of the Spring framework. Googling around you find very little articles and posts criticizing Spring. Most notable is Crazy Bob’s I Don’t Get Spring weblog. My blogs on…

]]> By: Re: The tension between transparency and abstraction, and some links « RubyHam http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-18 Re: The tension between transparency and abstraction, and some links « RubyHam Fri, 09 Feb 2007 21:37:37 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-18 [...] There’s a comment at the bottom of this article that strikes me as a good example of the circumstances that led to Rails’ ease of use / maintenance: I’ve struggled with this issue too. [...] [...] There’s a comment at the bottom of this article that strikes me as a good example of the circumstances that led to Rails’ ease of use / maintenance: I’ve struggled with this issue too. [...]

]]> By: blogs.swview.org » Blog Archive » Balancing Between Transparency And Abstraction http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-17 blogs.swview.org » Blog Archive » Balancing Between Transparency And Abstraction Wed, 31 Jan 2007 11:07:50 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-17 [...] As highlighted by Bill Higgins in his post, both transparency and abstraction have their own merits and compete with each other. Thoughts on balancing between these two in most cases leads us back to the basic principles software engineering. Some aspects that come to my mind are: [...] [...] As highlighted by Bill Higgins in his post, both transparency and abstraction have their own merits and compete with each other. Thoughts on balancing between these two in most cases leads us back to the basic principles software engineering. Some aspects that come to my mind are: [...]

]]> By: Bill Higgins / others on transparency and abstraction http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-16 Bill Higgins / others on transparency and abstraction Wed, 17 Jan 2007 21:02:53 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-16 [...] There’s a phrase from systems engineering that applies here, the principal of least astonishment. When an abstraction fails, a well-designed one will (hopefully) fail in predictable ways. It’s when an abstraction fails and it fails in an unexpected way that we have evidence of a leaky abstraction. Unfortunately, I don’t think this kind of behavior is avoidable, although it is the case that tracing down the roots of such failures and then refactoring the stuff at those roots will generally lead to a better separation of concerns. The problem is, in software, we generally never take the time to do that refactoring, and so we occasionally continue to be astonished at the most inopportune times. (more) Josh: [...] [...] There’s a phrase from systems engineering that applies here, the principal of least astonishment. When an abstraction fails, a well-designed one will (hopefully) fail in predictable ways. It’s when an abstraction fails and it fails in an unexpected way that we have evidence of a leaky abstraction. Unfortunately, I don’t think this kind of behavior is avoidable, although it is the case that tracing down the roots of such failures and then refactoring the stuff at those roots will generally lead to a better separation of concerns. The problem is, in software, we generally never take the time to do that refactoring, and so we occasionally continue to be astonished at the most inopportune times. (more) Josh: [...]

]]> By: Transparency And Abstraction on iface thoughts http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-15 Transparency And Abstraction on iface thoughts Thu, 11 Jan 2007 12:09:39 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-15 [...] Bill Higgins brings up the tension between transparency and abstraction. Abstraction has been beneficial for software development, in fact it is at the heart of the design principles. [...] [...] Bill Higgins brings up the tension between transparency and abstraction. Abstraction has been beneficial for software development, in fact it is at the heart of the design principles. [...]

]]> By: tech decentral » links for 2007-01-08 http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-14 tech decentral » links for 2007-01-08 Mon, 08 Jan 2007 23:29:02 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-14 [...] Bill Higgins / the tension between transparency and abstraction Are transparency and abstraction necessarily opposed? Abstraction removes details, but what if it hides extraneous details and makes the most important components and flows more obvious? (tags: abstraction transparency rest ajax architecture) [...] [...] Bill Higgins / the tension between transparency and abstraction Are transparency and abstraction necessarily opposed? Abstraction removes details, but what if it hides extraneous details and makes the most important components and flows more obvious? (tags: abstraction transparency rest ajax architecture) [...]

]]> By: Josh Staiger http://billhiggins.us/blog/2007/01/08/the-tension-between-transparency-and-abstraction/comment-page-1/#comment-13 Josh Staiger Mon, 08 Jan 2007 17:25:49 +0000 http://billhiggins.us/weblog/2007/01/08/the-tension-between-transparency-and-abstraction/#comment-13 I've struggled with this issue too. I haven't come to any concrete conclusions either other than to emphasize that abstraction *costs*. And not only does it cost, but it usually costs *more* than we think it does - because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on. I think this is one of the main reason why the überframeworks fail. When you try to build a framework in a vacuum, separate from a real application that uses the framework, you clearly don't have a good grasp of the costs of the abstractions you're creating. So I think whenever we create new abstractions we need to make sure we have very good reasons for doing so, and that we're not unwittingly creating more trouble than we're solving. I’ve struggled with this issue too.

I haven’t come to any concrete conclusions either other than to emphasize that abstraction *costs*.

And not only does it cost, but it usually costs *more* than we think it does – because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on.

I think this is one of the main reason why the überframeworks fail. When you try to build a framework in a vacuum, separate from a real application that uses the framework, you clearly don’t have a good grasp of the costs of the abstractions you’re creating.

So I think whenever we create new abstractions we need to make sure we have very good reasons for doing so, and that we’re not unwittingly creating more trouble than we’re solving.

]]>