Extreme Normal Form Commentary
Extreme Normal Form CommentaryThis page is for commentary on ExtremeNormalForm, quoted below for convenience: (in violation of OnceAndOnlyOnce)
Pleas for concrete definition
Have you ever learned something by rote and then had it click for you? Once it clicks, you recognize that your understanding is somewhat deeper but when you want to explain it to others, you start using offbeat analogies to herd rather abstract notions into an accessible form. This happens with the pattern people quite a bit. What is the quality without a name? Why do people want to point at similar things instead of naming the quality?
RichardGabriel talks a bit about the notion of "compression" in his book: the idea that a piece of text is bigger than itself because of the meaning that its context lends to it. Compression is common in poetry. Normal form is compressed above. We come to it with the concept of normal forms for databases; we also come at it with the idea of normality: typical state. How can something be both extreme and normal? It sounds like a paradox, but it isn't. ENF is the normal state which results from extremity. Could OnceAndOnlyOnce describe a normal form? All redundancy has been removed.
Is the description of ENF poetry? That would be neat. The MyersBriggs profile ENFP fits well... another layer of compression. Is it for beginners? Not really, it is filed under Curiosa in ExtremeProgrammingRoadmap. The fun thing about analogies is that each imparts understanding from a different direction. ExtremeNormalForm can also be given a straight-forward definition. Are there other qualities that are not listed in the first line on the page? Should we break them out?
. . . . .
I feel intimately familiar with the author's analogies, and have enough varied programming experience that I know the handful of XP practices mentioned above, and what it feels like after having done them. I've worked on projects where we've performed this XP subset, but not all the practices mentioned in XP. For example, we still used informal code reviews (there were two sets of us working in pairs and each pair would do a walkthrough of the other pair's code). We still used comments too, though not tons of them.
So if I know this feeling from prior experience with some, but not all of XP, is it possible that my code was in XNF too? How do I know which subset of the XP practices are the necessary yet sufficient ones to do this? Do small methods & classes, and tireless refactoring, OAOO and unit/regression testing suffice? Could an even smaller set achieve the desired effect? Can it only be ALL of the XP practices that impart this feeling?
When I saw a page describing some kind of "Normal Form" I had the expectation of some kind of objectively observable criteria or structure (in the geometric sense). I still need some brave soul to struggle with the essence of this visceral non-verbal feeling, and help me visualize the "form" that gave birth to it. -- BradAppleton
Okay, I own up to it. I wrote ExtremeNormalForm. I'm glad so many people liked it. It is about the state of the code. All the code you use is tested. All the code that isn't tested doesn't exist. :-) No one on the team can think of code in the system that they could remove or simplify without reducing the feature set. And, you never have to go more than one place to change one thing. This puts the code in an optimized baseline state for change: equipoise between what is needed now and an uncertain future. The consequences are... if you make mistakes you have a stable point to fall back upon. That point is as simple as things can be while still maintaining what the customer currently needs. The code is in complete alignment with the customer. Nothing is superfluous. If everyone is happy with the current capabilities, you can keep the software in ExtremeNormalForm indefinitely. It is the minima, the most understandable state, and amazingly, the readiest state for change. -- MichaelFeathers
Aspects of ExtremeNormalForm:
Connection to shrinking code
I am reminded of maintaining a system, early in my career, where I ended up deleting more code than I added. I had stumbled upon the awesome power of the delete key. Adding and Deleting. Darkness and light. yin and yang. Two sides of the same coin. Both can make a system better. (I think I caught a Zen buzz from the poem above).
I've had this feeling, and I'd like to have it again and again. What if we could begin to define just what ExtremeNormalForm really is, how to reach it? That would be great!
. . . . .
CartersCompass: I know I'm on the right track when by deleting code I'm adding functionality. -- JohnCarter
At OOPSLA98, I heard Kent and KenAuer talk about ripping code out. It was reassuring. I've been in the situation of being told not to remove unneeded capabilities and code from a build because they were viewed as assets. For me, that has never been enough of a reason to trip over them time and time again. Since learning about XP, I've been ripping out code (calling it refactoring in my mind), knowing that it was always in version control if I ever needed it. Throwing things away is one more way of saying that you are not scared. It expresses the confidence of being able to do things again. We are the assets. -- MichaelFeathers
Kudos and resonance
"I HaveThisPattern!" From my experience with martial arts, Eastern philosophy, and even sometimes in programming, I've experienced perfect moments like the one so beautifully described here. It's well-captured - congratulations to the author!
There are different ways to make SoftwarePreparedToChange?. The above is an excellent description of the feeling I get when my software is prepared to change according to the practices of ExtremeProgramming. I wish I had written it, but I didn't. -- KentBeck
Beautiful. Truth beyond truth. -- RonJeffries
The top piece of text I find more wonderful than anything else on this page, and on many other pages. Full kudos to the hidden master, who is welcome to stay hidden, as far as I am concerned. Actually, I just copied it to my hard disk, in case it gets damaged up here. cheers -- AlistairCockburn
Normal?
The description of what it "feels like" is splendid. I can definitely relate to it. However, I don't follow the relation between that, and a description of a "normal form" (or a "normative form"). Perhaps the original author could provide explanation or insight to ExtremeNewcomers? who haven't yet mastered the experience by defining what XNF is in addition to describing what it feels like. That way I could get a better sense of what the form is (to supplement the knowledge of what it feels like). -- BradAppleton
I've appreciated the poetic XP expression since it was first posted. However, if the goal is now to draft ExtremeNormalFormDefined, I must ask why the word "Normal"? Why not say "Your code is in ExtremeForm?"? Are there gradations or states of the ExtremeForm? that I'm not aware of, but that would be NonNormal?, or PartiallyNormal?, etc? -- JoshuaKerievsky
I take it as a play on words relating to the relational concepts e.g. Third NormalForm, referring to getting things into a standard form. It meant something to DrCodd.
The Normal in ExtremeNormalForm refers to right angles, not to normality. It implies that if you can make a change one place (one axis), without affecting anything else. Movement in any dimensions does not affect the other dimensions. I feel that this is somehow missed in the definition, however. It refers to methods (OOAO, YAGNI, etc), not to ideal results (ease of independent change).
ExtremeNormalForm bothers me immensely when over-applied. I see hundreds of methods with only one point of call. A simple, straightforward sequence of operations is now scattered about the code without regard to order. Inlining and a comment (or not) would be preferable in these cases. Yes, a method should not be unnecessarily complex. But if you take a half-screenful method and break it into pieces, now consuming two screenfuls of one-line methods. Why?! Why must people make code like this? -- AredridelStewart?
Of course you are spending all your time tracing all the very small classes while trying to build up the model of how it works in your head.
ExtremeNormalForm is not possible without a functional language (need closures, map, fold, zip, etc.) to achieve ENF. ENF cannot be achieved in languages that provide looping constructs like while, for, foreach, etc. because you are always rewriting loop conditions with the same properties. Instead of writing the loop once, you are writing it every time you have a loop.
See OoVsFunctional
While roll-your-loops might simplify things a bit, it is only accounts for a few percent. It is hard to beat "while[condition]{ }" WRT less code.
Although if you're iterating over a collection this can easily be turned into:
collection.select(somePredicate).apply(someFunction);assuming you have a decent collection library along the lines of BlocksInJava.
Norman
There is an alternative to the ExtremeNormalForm - the ExtremeNormanForm.
Dissenter's View
Taken too far, this pattern destroys legibility. A clear ten-line block of code is more comprehensible than an obscure, rarely used and poorly named function.
Incomplete normal form, where a chunk of code is halfway normalized but still duplicated throughout the project is worse than either extreme - it's like scented kitty litter.
Maintenance programming tends to erode normalized code, because it is always easier to copy a working chunk of code than it is to write a new normalized function.
I once worked on a project where there were pages and pages of duplicated code. If you paged down really fast it had the similar illusion to wagon wheels spinning backwards on film, the illusion of paging up when you were paging down.
-- Russell
EditText of this page
(last edited November 27, 2005)
or FindPage with title or text search