202406271256 Essential XP: Emergent Design

An article we read as a group for a discussion in our engineering organization. The author explicitly offered all his conclusions as fact "without much justification" noting that "at some later time, perhaps I’ll try to justify this view."¹ I did not agree with what little it did contain.

There are many well-known modeling and design techniques that can be used to bring about a "good design". An incremental process may limit the applicability of these techniques, which are most powerful when applied and committed to "up front". Test everything; eliminate duplication; express all ideas; minimize entities: These few simple rules, applied locally, can help a high quality global design to emerge.¹

Ron asserts that good design is highly modular, consisting of separate components (typically objects) which are highly cohesive, loosely coupled, and given expressive names that enable us to grasp quickly what the modules mean and why they are there.¹ This statement is the most reasonable of the article. I agree with it, but I find it to be vague to the point of being unhelpful. For example, I'd rather be the right temperature than very hot or cold, but that doesn't offer much as to the nature of "the right temperature". Being the right temperature is tautological. His design principles aren't as self-evident, but they can be interpreted in almost any way to fit or reject a design as "good".

He continues on to discuss Kent Beck's "rules" for simple design:

1. It runs all the tests
2. It contains no duplicate code
3. It expresses all the ideas the author wants to express
4. It minimizes classes and methods

However, he immediately contradicts himself in the few sentences he writes about each of Beck's four points, undermining any credibility the reader might have granted him (at his request at the outset of the article).

Observations for discussion

Regarding the suggestion to replace a switch statement with multiple classes, polymorphism, and methods. Jeffries asserts that this more fully expresses the ideas the author is meaning to convey. I disagree with this change as subjective and situational at best. More importantly though, why on earth would someone want to do that at all? Why would I want to destroy 202406282245 Locality of Behavior and shred the reader/maintainer's ability to process the function and behavior without jumping between many files? This also contradicts minimizing classes and methods. The proposed refactor is beside the main point of the article, but failing to identify the contradiction with the very next paragraph is egregious. If we can't be internally consistent across the span of two paragraphs, how can we sort through the complexity good and bad design of programming in the real world? Yes, yes, ad hominem and all that. I hear you.

Why do all of these "design pattern" and "principles of design" type books and articles pre-suppose a strongly OOP paradigm? I think it's a clear indicator that they were not actually uncovering what it means to have a well designed system — nor an efficient, maintainable, or performant one for that matter. How could these so called "principles" be fundamental to good design if they could not be applied across paradigms, situations, and time? The answer is that these were all unsupported, unscientific personal opinions written through the lens of the trends of the day — Agile, XP, OOP — for personal status and profit; i.e. they were grifts.