I just added a new post which has some overlaps with this one, hence this retrospective comment/response.

-Ian

Suppose you rewrite a program with tangles using a language that is similar to Java but supports structural subtyping. With such a language eradication of tangles is really easy.

So, the new version of the program will have no tangles. Using tangle-count as a quality indicator, we improved the design by an infinite factor (from some n to zero).

Do you really think that the architecture of the new version of the program will never-erode? Do you think it will be much easier to maintain it?

Thanks for making this post. Although I don’t agree with some of the points, they are very well argued.

I didn’t mean to bash neither you nor S101. If it came out that way it was unintentional and I apologize for that. My problem is with the static analysis approach as a whole. I am not saying that the approach is always wrong. However, it is definitely sometimes wrong (see formal proof in link-1, below).

I think the software development community does not yet know where exactly the boundaries of the approach lie. I am trying to help us draw these boundaries by highlighting examples where the approach does not work.

Anyway, in order to keep this debate manageable, I will only put my main comments here, starting from the most important one.

“in order for design items to be first class citizens in the code-base, we need to be able to see them and, especially, the interactions between them.”

First, some programs enjoyed great benefits from design items that are not first class citizens in the code-base. Any external DSL (and to some extent, internal DSL) is not a first class citizen of the code base. Other examples: the property pattern, adaptive object models, table-driven programming.

Second, the introduction of interfaces to solve dependency issues makes it more difficult to see the static interaction between the collaborating classes. The statement in this quote is quite similar to the one made by Fowler’s “To Be Explicit” article (see link-2). One of the examples there argues that the observer pattern makes relationship less explicit which is bad. However, this is at odds with the “tangles are bad” approach. Again, a small conundrum.

I am not saying programmers cannot solve this conundrum by relying on their wits, experience and skills. I am just saying that indiscriminate application of what I call “formulas” is likely to get them into troubles.

“As I said in the opening paragraph of the original post, the key for me is levels of abstraction above the raw code: architectural components within a code-base if you like.”

Abstraction means losing (inessential) details. Could you rationalize why the details that are *not* shown by S101′s views (in particular, runtime behavior) have a lesser impact on quality than the details that *are* shown? I assume this would be hard due to (again) the lack of this “magic-quality-metric”

“In the case of findbugs, there are several instances where you can see that an architectural decision was made, only for this to become blurred and ultimately lost over time.”

How do you know that the lost of the initial intention was not deliberate nor fruitful?

“but it is essentially up to you (the user, team, …) whether or not you choose to care about this”

I couldn’t agree more. The information exposed by static analysis needs to pass through a project-specific-filter. Without an “external intervention” it could be interpreted in many different, probably wrong, ways.

Link-1: http://javadots.blogspot.com/2008/12/formalizing-paradox.html

Link-2: http://martinfowler.com/ieeeSoftware/explicit.pdf