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: "Adam Chan" <email@hidden>
- Date: Tue, 26 Aug 2003 14:16:09 -0600
Well put Chuck.
There are plenty of good OOP books or documents out there already. For
instance, the one (OOP and The Objective-C Language) included with
WebObjects isn't bad at all. I found an online version here:
http://www.toodarkpark.net/computers/objc/objctoc.html
Not only "many developers are seemingly unable or unwilling to make real use
of (OOP)", but also many of them simply have no passion on making good
software. What is good software anyway? To them, it has output and doesn't
crash which they can show it to the boss or customer, than it is good.
Software engineer make good money and that is the only reason they study
Comp Sci and become a developer.
----- Original Message -----
From: "Chuck Hill" <email@hidden>
To: "Arturo Pirez" <email@hidden>
Cc: <email@hidden>
Sent: Tuesday, August 26, 2003 11:57 AM
Subject: Design, Architecture, and Thought Processes (Was Re: shopping
carts)
> Hi Arturo,
>
> I'm not sure where this will go, but it seems like an interesting topic...
>
> I've seen similar things. I once worked with a "senior" developer
> with a Masters in Comp Sci. I'd worked with him at another place, and
> in a different OO language, and he seemed to be good. Obj-C, however,
> mystified him. He was unable to discern the difference between
> instance variables and method parameters, despite years of experience
> working with this in other languages. I was stunned.
>
> I think part of the problem is an expectation, even a demand, that
> things be a certain way. When they are not some people are simply
> unable to make the jump. They continue trying to force concepts into
> a framework in which they simply can't fit.
>
> A related problem is anticipation of complexity. If someone believes
> that they have a complex problem they tend to look for a complex
> solution. This has some basis in experience, often a complex problem
> does require a complex solution. However, I've seen a lot of people
> make a simple problem out to be much, much more complex than it is.
> Usually this results from being less than clear on the requirements of
> what is needed and focusing instead on too large a picture. They then
> reject out of hand the simple solution that would have satisfied their
> needs and march resolutely on designing a complex solution. I suspect
> that this is the source of grief in many failed shopping cart
> implementations.
>
> 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. It sounds to me like your
> senior developer below has this bad, perhaps coupled with an incorrect
> assumption of how it all went together. 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.
>
> I've been thinking for a while of writing an article, or a book, or
> something following the development process at a personal level. I've
> no interest in putting forth yet another design process, but rather to
> chronicle a real life problem and all the considerations, false
> starts, analysis, and decision processes that go into it. Perhaps
> what I have in mind is sort of a project diary. I think it might be
> instructive for those starting out to see, in detail, how a more
> experienced person views a problem and how they approach solving it.
> One of these days...
_______________________________________________
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.