tag:blogger.com,1999:blog-10280668.post2269842031547175784..comments2023-09-22T06:05:17.495-05:00Comments on Brad Appleton's ACME Blog: JEDI Programming - Just Enough Design InitiallyBrad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-10280668.post-22919027620353307972009-11-08T08:21:35.555-06:002009-11-08T08:21:35.555-06:00Just a follow-up (albeit late), at Agile 2009 I at...Just a follow-up (albeit late), at Agile 2009 I attended a session by <a href="http://www.nealford.com" rel="nofollow">Neal Ford</a> on "Evolutionary Architecture and Emergent Design" which in turn is based on material from his book "<a href="http://oreilly.com/catalog/9780596519780/" rel="nofollow">The Productive Programmer</a>"<br /><br />Neal also has a series of articles on the topic @ developerWorks.com and the introductory article has a graph of sorts that I think starts to get close to what I attempted to describe above for JEDI (see Figure 1 "Spectrum of Design" in the section titled "Defining Design" at <a href="http://www.ibm.com/developerworks/java/library/j-eaed1/" rel="nofollow">http://www.ibm.com/developerworks/java/library/j-eaed1/</a><br /><br />Basically the horizontal axis of the timeline shows how much before or after you do the design: all-up-front, incrementally up-front, immediately before (test-first), immediately after (as in refactoring), incrementally after (restructuring), rewriting/reengineering etc.<br /><br />Peppered about that timeline are techniques or practices such as evolutionary architecture, domain-driven-design, incremental design, TDD/BDD, refactoring, restructuring, etc. Each technique tries to place itself in the correct horizontal position on the timeline.<br /><br />Then "JEDI" itself is basically a "curve" across this horizontal axis (time) and vertical axis (size/complexity) that looks a bit like a bell-curve of sorts, the area under which indicates how much up-front, during, and after-the-fact design is appropriate. Projects of different size/complexity would have slightly different curves acknowledging the need for more up-front work.<br /><br />The area under the curve would correlate somewhat to technical-debt. Meaning the more you design too-early, the more technical debt you are creating for later, and the more you wait until its too-little-too-late the more you are accumulating without "paying down" your debt.<br /><br />And that would be the JEDI card. Its sort of like cost-of-change curve accept it is the cost of designing too-much-too-soon versus too-little-too-late with "JEDI" indicating the "sweet spot" (for a projects size/complexity and risk-threshhold [e.g., spaceshuttle launches])<br /><br />The "techniques" that fall on the appropriate points in the horizontal timeline would likely also correspond to other cards in the tech (TDD, BDD, DDD, Refactoring, Restructuring, Emergent Design, Incremental Design, etc.)Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-45502647535186998632009-07-20T19:32:45.224-05:002009-07-20T19:32:45.224-05:00Hi Scott! Thanks for your comment. While I agree t...Hi Scott! Thanks for your comment. While I agree that prefactoring, as a term, came about partly as a form of resistance to "emergent design", I think that misunderstanding from which it arose is a common one, and the same one that Uncle Bob complains about so strongly in his "Scatology of Agile Architecture" posting.<br /><br />This is a misunderstanding that is all too easy and all too common to have, precisely because "JEDI" is not explicitly emphasized (certainly not enough) in the dissemination of most information about refactoring, TDD and emergent design.<br /><br />This article uses the definition of refactoring that Ken Pugh used in his article that attempted to clarify what it meant from the hype and marketing associated with the book (It was not quite so extreme a counter-reaction to emergent design as many had thought).<br /><br />While refactoring and prefactoring are both forms of factoring which are in turn forms of design, they carry a specialized enough meaning that is more specific in scope and timing as to not simply be synonomous with "design".<br /><br />Therefore, it has its place on any spectrum that compares the time/timing of the design that is done along with the amount (big vs small, too soon vs too late, and everything else on both sides of the "just enough & just in time" spectrum.<br /><br />I was actually kind of surprised that of everything said in the article, you seemed to focus exclusively on this one small aspect of it. Is "prefactoring" a "hot button" that is the cause of bad blood/feelings by many in the agile community?Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-71214373284601771192009-07-19T15:24:30.388-05:002009-07-19T15:24:30.388-05:00Hi Brad,
I think that there's value in recogn...Hi Brad,<br /><br />I think that there's value in recognizing the historical context of pre-factoring and not fail to recollect that it was largely an opposition to emergent design rooted deeply in not having the firmest grasp on the meaning of refactoring at the time.<br /><br />This article seems to use "pre-factoring" as a reflection of "refactoring". Almost every appearance of "pre-factoring" could be replaced with "design".<br /><br />I don't particularly see pre-factoring as synonymous with design because pre-factoring is a response to refactoring.<br /><br />It might seem logical that pre-factoring is the opposite of refactoring, but there is no opposite of refactoring, as refactoring is also just design. No design or no maintenance of design might be the opposite of factoring and refactoring.<br /><br />When the factoring turns out to be imprecise or no longer appropriate, we redo it: refactoring.<br /><br />Whether the factoring is done far in advance of proving its applicability to reality or if its done just before implementation, it's still just factoring, and factoring is just design.Anonymoushttps://www.blogger.com/profile/10851121926952875016noreply@blogger.com