[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Don't Let Architecture Astronauts Scare You
my 2c on this is that it all depends on you failure allowance. If I am building a computer program to control a mars probe I may want to design and implement the best that I could. But in most cases especially with redundant servers etc ... do we really need a program to NEVER fail and be flexible to the point that it can mold it self to become anything in the future. Balance this out with the limited resources that most projects have ( developers , servers ). I am beginning to believe in disposable software for many applications. I know this sounds very "extreme programming" - ish but my belief on this is that until you actually get your hands dirty on a project and you get some feedback from the people using the tool ( or whatever it is ) you don't really have enough information to judge what the best usage of design effort is. Most projects are over designed and over engineered and many miss the mark. Not because of bad engineering but because there is not enough information to design the project for even 1 year in the future. That being said. You can learn patterns. You can see commonality between similar projects. So this experience will guide you to take the best first guess. I guess it is sort of like an iterative solution where you take a stab in the dark. Get everything running. At that point if you need to write it over and redesign what you have I would bet you have a much better understanding of the problem at hand than you did the first time around. After a few of these iterations the direction of the technology becomes clearer. My philosophy is keep design time to a minimum. Certainly keep the number of people involved in any one meeting to a minimum. Start off with a fairly general spec. Then build additional attributes into it. Refactor at each iteration. If you see a chance to build in some flexibility that doesn't cost much ... do it but don't spend weeks making something overly flexible. Optimize as needed. -----Original Message----- From: Matt Gushee [mailto:mgushee@h...] Sent: Monday, September 16, 2002 6:58 PM To: xml-dev@l... Subject: Re: Don't Let Architecture Astronauts Scare You On Mon, Sep 16, 2002 at 02:13:35PM -0400, Jonathan Robie wrote: > At 01:56 PM 9/16/2002 -0400, Mike Champion wrote: > > >Joel Sapolsky's rhetorical excesses aside, I think his point needs > >to be carefully considered. The architecture of products we use > >year in/year out tend to evolve from the experiments of individual > >craftpeople rather than being handed down by the Intelligent Designer. > >"Architecture" can be the art and science of figuring out the > >enduring principles of things that actually work, rather than > >building abstractions that can live only in the rarefied air of > >pure thought. > > But when you study what the "things that work" have in common, the result > is an abstraction. For instance, a design pattern is an abstraction that > came from looking at a whole bunch of code that solved the same problem in > the same way. I think it's OK to have designers, they are allowed to be > intelligent, use abstractions, and think. I'd like to offer a hypothesis that may satisfy both (all?) camps in this debate. Or perhaps annoy everyone equally. Either way, here it is: * Good design is disruptive. It upsets the status quo because (especially in North America), we are surrounded by shoddy products, ad hoc solutions, apathetic service, and half-baked plans. And a great many people, even if told their professional or personal lives could be better, prefer to muddle along with the various devils they know rather than undertake the effort to think or act in new ways. * Well-designed tools, to really make a difference, often demand growth on the part of their users. Compare, say, a Mercedes and a Buick (I've never driven either, so I'm going by hearsay). Now I would predict that almost anyone who is fully engaged in the driving experience would prefer to drive a Mercedes ... but if your mind is focused on trying desperately to make the meeting on time, while your cell phone is buzzing, the radio is blaring, and some idiot just cut you off ... who cares? Go for the Buick: it's cheaper and probably a bit easier to drive. Or suppose you're a Java programmer (and maybe you learned C++ in school, if you studied computer science at all), and your company asks you to build an XSLT presentation layer for its fabulous new eCommerce application. Do you invest the time to learn what XSLT is all about, so that <xsl:apply-templates select="foo[@bar > 41]" mode="baz"/> becomes the obvious solution to many problems? Or do you stick with what you know, and produce something like: <xsl:for-each select="foo"> <xsl:if test="@bar > 41"> <xsl:call-template name="doBaz"> <xsl:with-param name="foo" select="."/> </xsl:call-template> </xsl:if> </xsl:for-each> ... and curse your boss for forcing you to work with such a horribly awkward and verbose language? (This is based on a real-life example, by the way) * Good design by itself is rarely enough. Products must follow the design both in letter and in spirit, and end users may need information and incentives in order to take full advantage of the well-designed products. * For both cultural and economic reasons, we have learned to want quick technological fixes. Companies want to avoid the costs of training, and more subtly but perhaps equally important, the effort of building real consensus for technological change. Technology vendors and consultants are generally ethical and concerned that their products and plans be deployed correctly and used effectively ... but few are willing to risk lost sales by revealing the true cost of change (assuming they are aware of it themselves). * Therefore, "worse is better." I strongly doubt that this is a universal principle--at least, I'm fairly sure it is not equally true in all parts of the world--but it is a reality in the settings where most of us live and work. So I would conclude that designers who are willing and able to follow through on the social and economic implications of their work have a chance of truly benefiting business and society. Those who believe that good technology is good enough may, with the best intentions, be imposing on organizations the costs of change without enabling them to reap the benefits. -- Matt Gushee Englewood, Colorado, USA mgushee@h... http://www.havenrock.com/ ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl> ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|