Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!transit3.readnews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Standard Design and Development Methodologies Date: Fri, 25 Nov 2011 20:07:29 -0800 (PST) Organization: http://groups.google.com Lines: 56 Message-ID: <4013019.261.1322280449872.JavaMail.geo-discussion-forums@prfi36> References: <4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19> <4ed05449$0$283$14726298@news.sunsite.dk> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 173.164.137.214 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1322280450 21271 127.0.0.1 (26 Nov 2011 04:07:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 26 Nov 2011 04:07:30 +0000 (UTC) In-Reply-To: <4ed05449$0$283$14726298@news.sunsite.dk> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.214; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10261 Arne Vajh=F8j wrote: > Lew wrote: >> There's a comprehensive little pamphlet reviewing various software >> development methodologies called /Wicked Problems, Righteous Solutions/ >> by DeGrace and Stahl, 1990, that is as relevant today as when first >> published. >> >> Its main conclusion, after a very neutral overview of the extant pet >> theories, is that successful methodologies rest on two key features: >> an individual who maintains the project architecture and structures >> in his/her own mind, >=20 > It is obviously correct. >=20 > But it is not very useful. >=20 > Creating good software when one person can understand the > entire app is the easy problem. >=20 > Creating good software when one person cannot understand the > entire app is the hard problem. You are correct, but bear in mind that I provided only a very few words of = summary for a rather detailed, patient analysis and set of conclusions in t= he original work. Before judging their conclusions you might want to be su= re that you understand their point more directly than by hearsay from a ver= y cursory precis. As best I understand the book it is their conclusion that even the second c= ase requires a person to understand the entire app. This apparent paradox = is resolved by understanding that the overview knowledge, while detailed, i= sn't necessarily atomic. It's a matter of someone exercising a form of lea= dership to assure consistency and a certain focus in a project. By analogy= , the chief executive of a nation need not understand necessarily every sin= gle detail of every action occurring in every corner of their realm, but th= e should have a keen grasp of the nation as a whole and a vision for its di= rection. This is the sort of "understand the project" that I infer and rem= ember from the book. I conclude that a project that grows beyond such a vision needs to have fra= ctal subprojects that fit within such scope and operate with some autonomy. This is a direction that might address the valid point you raised. I recom= mend the book not so much to endorse its conclusions as to commend its even= -handed and comprehensive analysis and the segregation thereof from the aut= hors' agenda or theories. While it draws conclusions in the latter part of= the book, it does not go so far as to recommend anything. They have no pe= t buzzword or system to promote, only observations as to what works and fai= ls under different methodological structures. It's a foundational work. As to how "useful" their conclusions are, I'll let you judge for yourself a= fter you've bypassed the filter of my reporting. I'd be surprised if you m= aintained your dyspeptic view after that. --=20 Lew