Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- Subject: Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
- From: Arturo Pérez <email@hidden>
- Date: Wed, 27 Aug 2003 08:36:57 -0400
On Tuesday, August 26, 2003, at 01:57 PM, Chuck Hill wrote:
Hi Arturo,
I'm not sure where this will go, but it seems like an interesting
topic...
I've snipped out what I think are the problems I've seen and that I've
wanted to comment on.
I think part of the problem is an expectation, even a demand, that
things be a certain way. ...
This is something that's true in all walks of life. McDonald's even
makes a business out of it. I've
found it to be something particularly vexing in software development.
Is it only software engineers that
want to use a hammer for _every_ problem? Things like people only
wanting to use Perl or Java or servlets
when it doesn't really make any difference to the problem at hand.
... I've seen a lot of people make a simple problem out to be much,
much more complex than it is. ...
In my world I've seen the opposite (me, I like complexity :-).
Developers thinking that complex things
had to have a simple answer. It's generally a symptom of not thinking
things through. And of settling
on a solution before fully understanding the problem. In other words,
the developers "pick" a solution
and then in the face of problems/deficiencies of the solution they
apply point solutions. Something like
well, it won't scale, so I'll add another box. Oh, that's too slow so
I'll keep adding boxes until
it's fast enough.
But they do that sort of things with algorithms/designs, too. "This
case fails so I'll add a switch to
detect it."
The last problem that comes to mind is the desire to know absolutely
every detail of the implementation of the code being used, rather than
relying on the abstractions it provides. ...
Open source has only made this worse. And it does no good to tell
people, "you're job is to use the frameworks
and report bugs if you find any. But what you're doing is so simple
you won't find any." I haven't met a coder
in 5 years (or is it 10) that can work from documentation or
specifications. Everything has to be an example.
"Perl cookbook" indeed.
Although abstraction would seem to be a common, well understood
concept (not to mention a core facet of OO), many developers are
seemingly unable or unwilling to make real use of it. That is a real
productivity killer.
This is a known quantity. I saw somewhere that only 1 in 20 developers
can deal with abstractions. What bugs
me is that many developers automatically equate abstraction with
"performance killer." That is, the attitude
that "if I don't twiddle the bits directly then it'll go too slow."
-------
WebObjects in Philadelphia. You want a cheesesteak with that?
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.