tag:blogger.com,1999:blog-13967713.post2122354707672817919..comments2016-05-11T20:05:39.322+02:00Comments on Carlo Pescio: Delaying DecisionsCarlo Pesciohttp://www.blogger.com/profile/12652284939993729858noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-13967713.post-42135070085365197322010-02-08T15:18:01.842+01:002010-02-08T15:18:01.842+01:00I think it could be a great to dissect an example ...I think it could be a great to dissect an example like a distributed db application could be more interesting from different points of view, not only for the forcefield diagram, but even for delaying decision, and I believe for architecture also (example: agile emergent design of db application, java and .net marketecture). I guess it will take more than a year to exhaust the topic, but shift from theory to practice could be difficult :)Anonymoushttps://www.blogger.com/profile/04630127186004942157noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-25712793812681366602010-02-08T11:31:16.490+01:002010-02-08T11:31:16.490+01:00Fulvio: right, there would be a lot to say. It wou...Fulvio: right, there would be a lot to say. It would also make a perfect fit for some real-world applications of the forcefield diagram. I'll think about it!Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-69460924891295551022010-01-26T10:07:50.282+01:002010-01-26T10:07:50.282+01:00Thanks a lot Carlo for the comment! Have you ever ...Thanks a lot Carlo for the comment! Have you ever thought to write some article about your way to design a modern DB application? You wrote about this some time ago for 2-tier architecture and a little bit on this blog, it could be interesting to dissect more in depth :-)Anonymoushttps://www.blogger.com/profile/04630127186004942157noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-23977235315850587262010-01-25T17:02:46.880+01:002010-01-25T17:02:46.880+01:00Fulvio: I kinda like it. Of course, you have to le...Fulvio: I kinda like it. Of course, you have to learn how to use it properly, and you have to accept the fact that it will percolate just about everywhere in your code. Once you're cool with that, Seam (or any other Seam-like technology) can save you a lot of boilerplate code, and help you write more loosely coupled code.Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-2669038103716761062010-01-20T09:59:15.472+01:002010-01-20T09:59:15.472+01:00" you can postpone the choice (well, even the...<i>" you can postpone the choice (well, even the waterfall guys did :-). "</i><br /><br />...It still hurts. ;-)Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-17188938095032603432010-01-18T15:20:10.945+01:002010-01-18T15:20:10.945+01:00there's a quotation, so I'm not completely...there's a quotation, so I'm not completely out of topic. Could you give some opinion about JBoss Seam? They could be useful for a future decision :-)Anonymoushttps://www.blogger.com/profile/04630127186004942157noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-18524481300408824152010-01-17T18:26:31.609+01:002010-01-17T18:26:31.609+01:00We chose a language, of course, but it was a parti...<i>We chose a language, of course, but it was a partially reversible decision.</i><br />hmmm... that's why I defined irreversibility as "if you make an irreversible decision at time T, undoing the decision at a later time will entail a complete (or almost complete) waste of everything that has been created <b>after</b> time T"<br />Using a different language to carry over analysis and design gives you an opportunity to delay the choice of a programming language. After you choose, however, <b>that</b> decision is irreversible in the sense above. Of course, you won't waste what you have done <b>before</b> that point.<br />So I would contend that choosing a programming language is still irreversible, but of course, you can postpone the choice (well, even the waterfall guys did :-). <br />Note: I'm using "programming language" with the original meaning of "the language you use to write code". Using a code generator, for instance, makes the choice of a language rather reversible (but that's not, strictly speaking, a "programming" language), assuming you don't fiddle with the generated code at all (which is usually not the case :-)<br /><br />I totally agree on the cognitive load of keeping many choices open - that's why, as you said, many people would rather go with sub-optimal choices "now". <br />I tend to use visualization to keep the task manageable - in a sense, a lot of what appears in a forcefield diagram can be used to postpone some decisions, or to find new ways to make some decision invariant by tweaking the forcefield...Carlo Pesciohttps://www.blogger.com/profile/12652284939993729858noreply@blogger.comtag:blogger.com,1999:blog-13967713.post-63251806674038678982010-01-13T13:28:37.177+01:002010-01-13T13:28:37.177+01:00Really nice post. Wow.
There's something abou...Really nice post. Wow.<br /><br />There's something about the idea of Last Responsible Moment that stroke me during Christmas Time: you can't negotiate or postpone Christmas, so you have to make some "reverse planning" about what to buy as presents and when, and allocate time accordingly: by December 15th I'll have to know which presents I will buy and to whom. Unfortunately I am not good at that. :-(<br /><br />In some cases, choosing the language might not be as irreversible as it used to be. I've found myself in a situation where we really wanted to keep the language choice open, so we stressed expressing requirement on a language independent tool to develop a domain model prototype. The hard job was in requirements gathering and translation into tests, fulfilling the spec was somewhat a simpler task. We chose a language, of course, but it was a partially reversible decision.<br /><br />In general, I am a big fan of LRM but I have to admit there's a drawback in that: the number of decisions still to take is a burden itself. Some teams might not feel comfortable with that, and make decisions just for the ancestral need of not having so many options open all the time or to deal with a simplified, more manageable landscape. I like keeping many options open, but this might look scary to some.Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.com