This obviously is mostly smoke and mirrors. Uncle Bob recycles Separation of concerns [1] and overshadows it in the process. You won't define what are good or bad boundaries in code anymore than you will define "5 easy rules to author a great piece of fiction". The computer doesn't give a damn about separated concerns, it's all about communication between humans. As such it is a matter of feeling, dare I say emotion, and not a matter of laws and rules. Ultimately our ability to break problems in sub-problems tends to be bounded by the words we have at our disposal.
The TCP/IP stack exemple in the Wikipedia article linked below hints at SoC pretty well in my opinion. One layer allow the layer above to disregard details about the physical link. The next layer makes cross-network addressing transparent. The next one allows apps to disregard packet ordering and loss, and so on. Each layer solves a problem for the one above. Yet one can have multiple responsibilities. This is all about cognitive load.
A system described in code is nothing more than a proposed consensus around tools, names, boundaries, paradigms to be used to talk and think about a solution to a problem. The ultimate measure of success is this: our ability to tame the binary beast. If "change" plays a role (it sure does) it's probably not the main or only metric. Well ... when you're not selling "ability to change" consulting and books to software companies, this goes without saying.
Great post. I think this is the fundamental thesis proposed by Abelson and Sussman in SICP. You build a system in layers, each relying on the one below.
The reason you do this is to manage cognitive load in humans, not "coupling" in computers.
First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems. [1]
I have to wonder if part of the reason there's so much bickering about this concept is that a lot of apps aren't a complex problem domain, but rather they just drown slowly in incidental complexity and feature creep.
IMO it stems from the fact that managers up the ladder don't understand or have never been told that software that produces the expected results isn't necessarily finished work. There is a reason most of us have this gut feeling, this strive for elegance. We can only be at rest when we feel we master the creature we have built, and can live up to our clients expectation of maintaining it and making it evolve. Managers see it under a different light. TDD was made for them, for they are those who buy it. At the end, cut the costs as much as possible. The system (still) gives the expected results ? Alright, job done. There is no consideration for the hell of a ball of mud that often drives the whole thing behind the curtain. Yet, at the end they are those who pay for hiring the wrong persons or following the wrong cult. This is how you get overbudget or fail a project. TDD ? Separation of concerns ? Why not, but the same goal of working and flexible code can be met by developing and encouraging good craft in a team. Not by luring people in adhering to practices that constrain them to do a bad job unbeknownst to them. Testing and structure stem from good craft, not the other way around.
The TCP/IP stack exemple in the Wikipedia article linked below hints at SoC pretty well in my opinion. One layer allow the layer above to disregard details about the physical link. The next layer makes cross-network addressing transparent. The next one allows apps to disregard packet ordering and loss, and so on. Each layer solves a problem for the one above. Yet one can have multiple responsibilities. This is all about cognitive load.
A system described in code is nothing more than a proposed consensus around tools, names, boundaries, paradigms to be used to talk and think about a solution to a problem. The ultimate measure of success is this: our ability to tame the binary beast. If "change" plays a role (it sure does) it's probably not the main or only metric. Well ... when you're not selling "ability to change" consulting and books to software companies, this goes without saying.
[1] http://en.wikipedia.org/wiki/Separation_of_concerns