• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Design, Architecture, and Thought Processes (Was Re: shopping carts)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Design, Architecture, and Thought Processes (Was Re: shopping carts)


  • Subject: Design, Architecture, and Thought Processes (Was Re: shopping carts)
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 26 Aug 2003 10:57:31 -0700
  • Organization: Global Village Consulting, Inc.

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...


Chuck

Arturo Pirez wrote:

On Monday, August 25, 2003, at 09:23 PM, Art Isbell wrote:

Basically, a shopping cart can be implemented by declaring in your Session class a NSMutableArray instance variable with appropriate accessor methods ... This isn't difficult to implement in WO.

<diatribe>
You know just about every WO newbie asks this cart question. And just about every time the answer is the same:
It's really easy! You just ...


Now, personally, I agree that it's easy (having done it). 99.99% of the effort in making the shopping cart is in getting it to meet the desires
> of the people asking for the cart.
But I also watched a senior engineer struggle with a cart for over 2
> months.  Part of it was that I gave him a framework that did
> all the validation and database work.  He spent at least 4 weeks trying
> to understand the validation logic.  To me it was strange because
> it was instantiate one of these do addOtBSoRwK, instantiate one of
> those do addOtBSoRwK, etc.
save it and catch the validation errors and make the user do it right.
But he didn't get it. So now I'm not too sure that it is as easy as we all know it to be.
</diatribe>


All that hot air being vented is it really as easy as pointing the newbies to WOPetStore?

--

Chuck Hill                                 email@hidden
Global Village Consulting Inc.             http://www.global-village.net

Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
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.

  • Follow-Ups:
    • Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
      • From: Chris Hanson <email@hidden>
    • Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
      • From: Ricardo Strausz <email@hidden>
    • Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
      • From: Arturo Pérez <email@hidden>
    • Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
      • From: "Adam Chan" <email@hidden>
References: 
 >Re: shopping carts (From: Arturo Pérez <email@hidden>)

  • Prev by Date: Re: the height is still not working...
  • Next by Date: Re: the height is still not working...
  • Previous by thread: Re: shopping carts
  • Next by thread: Re: Design, Architecture, and Thought Processes (Was Re: shopping carts)
  • Index(es):
    • Date
    • Thread