[
Lists Home |
Date Index |
Thread Index
]
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@havenrock.com]
Sent: Monday, September 16, 2002 6:58 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] 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@havenrock.com
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.
|
