RE: [AM] Article of Interest in CIO Magazine

It is my belief that great design is something that cannot be taught.
You either have the ability or you don't. You can't learn to be a great
musician or artist. You can't learn to be a great architect or car
designer. You can never learn to be more than adequate. It is inherent
ability that sets aside the great from the adequate and I think this is
as true of software as any other field of endeavour that utilises
design.
 
Unfortunately it seems we have no surefire way of identifying great
software designers or great software designs. Most of IT, IME, find a
pattern that kind of works and stick with it, even in the face of
repeated identifiable weakness or failure. The vast majority of software
is built as quickly and cheaply as possible to do perform specific
functions at a specific point in time utilising specific technology.
Even if it did have a great design then, which would be pretty unusual,
it is simply not designed to be flexible and adaptable over time.
 
There are a number of ways we can look at this. It maybe that disposable
software is actually a good thing. Technology change is so fast that we
cannot hope to build software that is capable of adapting in a cost
effective manner over time and it actually is cheaper to just throw away
and start again. It maybe that the demand for business results and the
way people move around means that anything beyond a 2 year horizon just
isn't worth planning for. It could be that the effective costs and
benefits associated with software just are not well understood. It could
be that we have no idea how to build malleable software. It could be
that certain accepted best practices actually mitigate against adaptable
software because they enforce rigid structures.
 
Personally I think all of these play their part, and until some software
companies are prepared to really 'think outside the box' instead of just
mouth the words, nothing much will change.
 
Regards
 
Ian Chamberlain

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: 08 March 2004 05:27
To: [email protected]
Subject: Re: [AM] Article of Interest in CIO Magazine


In a message dated 3/7/2004 7:22:47 PM Pacific Standard Time,
[email protected] writes:

Incidentally, I've never been satisfied with how development
methodologies address the issue of promoting design quality. Does anyone
have any thoughts on this?

Actually, that was one of the points I had intended to address in my
post, and I apologize for not explaining it more clearly or thoroughly.
(I think I just ran out of steam at the time!). 
 
One of the "unclarities" I have regarding virtually all of the agile
methodologies pertains to  system design, as in: "How do we build
complex systems "in the agile way" that are maintainable and
sustainable, when we know up front that we are looking at what might be
a very small subset of the requirements that the system might ultimately
be called upon to satisfy?" 
 
While the purists among us might suggest that we disregard those things
that are not known, because there is some likelihood that whatever work
we do on them may ultimately be unnecessary, and therefore a waste of
resources, the "impurists" might suggest that to do nothing in the face
of seemingly incontrovertible evidence that the system will require some
level of post-deployment maintenance or modification is irresponsible,
derelict, or worse. 
 
Now, 'fess up, boys: How many of you design systems in a manner that
facilitates post-deployment modification, even though this might not be
strictly in accordance with either the system requirements or the spirit
of agility? I do! I admit it! Go ahead, drag me down to the plaza in
downtown Los Gatos, where everyone will  laugh at my clothes!
(supposedly, the depths of Silicon Valley ignominy).
 
Hey, I'm kidding, at least the part about Los Gatos. They don't actually
laugh, they smirk! (I'm told: this is second-hand hearsay). Actually, I
suspect that this is the point at which the immovable object meets the
irresistible force. (Hey, it's a phrase from my youth; stuff like that
is in my genes!), In this case, it's experience versus dogma. 
 
I may be making too much of this, but it seems to come up often enough
in this forum (and others in which agile methodologies are diiscused).
It is, however, a topic that I've wondered about at times, and would
appreiate the counsel of the Elders on it.
 
Regards,
 
Pete
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------