What this BrightWork article is really talking about here is the process of adding abstract layers to the tool kit of a developer; a hallmark of object oriented programming. In this ever increasing libraries of already developed functionality are easily grafted into new development projects; which can obviously be a powerful productivity tool.

Everything has a downside though. It doesn't take many iterations of layers being created from the foundation of previous layers, and then new layers built atop of that, adnauseum. Not necessarily a bad thing, of course, but it can still be fertile ground for unexpected logic anomalies to be created; especially if one adds in the concept of "inheritance," and "polymorphism" that are also powerful aspects of object oriented programming. One can create a new class, with greatly expanded functionality, simply by starting with the inheritance of an old class, and then adding new functional code.

What can happen in all of this layering is that a problem can be the manifestation of subtle interactions between multiple layers, and the process of tracking back down through the layers to find it hardly trivial at all.

Another problem, in my mind, is that we are already well on the road to when a coder won't be necessary at all; what with the possibilities of a visually oriented development environment. In this context you have a gui interface that renders functionality into icons of various sorts, selected so that they make intuitive sense as to the functionality they represent. One then merely needs to select the icons of choice, make icon related links (of interactive functionality) between them and one has a functioning app.

This has been a significant guiding principle in web development for some time now as the idea has become ingrained that graphic artist oriented folks are much more suited to putting together what is essentially a visual experience. This too has been a useful development as it has also made it possible for ordinary folks to create quite complex web applications.

The problem, as I see it, is that, if we continue to rely on the "cost" mentality of an economic operating system bent on reducing costs, we could likely find ourselves in a situation where there are fewer and fewer actual coders who are able to dig down into the layers of code to find a problem; layers that might someday represent many decades of development. In fact, it might soon be the case that only other pieces of software would be able to do so, whose own inter-workings none of us would understand.

This would be, in my opinion, not a very good position to find ourselves in. It would also be an example of an aphorism I have been using for some time now: heaven help those who become too separated from that which sustains them.

Just something to think about when you view things through the lens of "cost" based assumptions.