The Artima Developer Community
Sponsored Link

Articles Forum
Tangosol's Cameron Purdy on the Importance of Design

12 replies on 1 page. Most recent reply: May 23, 2007 6:41 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 12 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Tangosol's Cameron Purdy on the Importance of Design Posted: May 17, 2007 3:00 PM
Reply to this message Reply
Advertisement
In this interview, Cameron Purdy contrasts upfront design with a coding-first attitude:

http://www.artima.com/lejava/articles/javaone_2007_cameron_purdy.html

When do you think each approach is most appropriate?


Eric Gillespie

Posts: 13
Nickname: viking
Registered: Jun, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 18, 2007 5:59 PM
Reply to this message Reply
I'm a novice programmer, and I may be repeating the obvious here, but I quite often hash out implementation before I really get into the design. I work with the bash scripting language to get simple (and sometimes complex too) jobs done, so for me at least, the line count isn't all that high. I can generally see the design and hold most of the important facets in my head because of this reason.
To code for a specific small job is easy. You code, and the design comes from that one taskset. However, when you're trying to make the code more generic, to do design when you don't understand really what it is you're trying to do (my normal target) is downright awkward, as I tend to <i>think</i> in code and specific tasks anyhow, rather than in concepts. That's just my twist on it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 21, 2007 6:35 AM
Reply to this message Reply
> I'm a novice programmer, and I may be repeating the
> obvious here, but I quite often hash out implementation
> before I really get into the design. I work with the bash
> scripting language to get simple (and sometimes complex
> too) jobs done, so for me at least, the line count isn't
> all that high. I can generally see the design and hold
> most of the important facets in my head because of this
> reason.
> To code for a specific small job is easy. You code, and
> the design comes from that one taskset. However, when
> you're trying to make the code more generic, to do design
> when you don't understand really what it is you're trying
> to do (my normal target) is downright awkward, as I tend
> to <i>think</i> in code and specific tasks anyhow, rather
> than in concepts. That's just my twist on it.

Designing before coding is something that is very difficult at first. You need to not only be able to imagine what the implementation will do but how it might do it. With experience, this becomes much easier. It's kind of like learning to drive. At first, you need to think consciously about where your feet are, how far to turn the wheel when you are steering. After a while, you internalize this knowledge. It becomes natural.

Having said that, it's not a bad idea to write a proof-of-concept before/when doing design. If I can't think of how I will solve a problem clearly, I find brainstorming in code to be an effective approach. Once I figure out what it is I'm trying to accomplish, I go back and write a clean design. The more experience I gain the less time I spend doing stuff like this. The key is to just cowboy-code the crap out of it. Don't spend a lot of time making it clean and pretty. You don't even need to complete it. Once the lightbulb goes on, you can stop. Save it for reference but it's basically garbage. You'll probably realize most of it's overdone or pointless. If you work under and idiot, don't let them know you did it. They may want you to use your proof-of-concept code in your final version instead of rewriting it.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 21, 2007 10:09 AM
Reply to this message Reply
James,

> Designing before coding is something that is very difficult
> at first. You need to not only be able to imagine what the
> implementation will do but how it might do it. With
> experience, this becomes much easier. It's kind of like
> learning to drive. At first, you need to think consciously
> about where your feet are, how far to turn the wheel when
> you are steering. After a while, you internalize this
> knowledge. It becomes natural.

Wow, that is a very good analogy!

Peace,

Cameron Purdy
http://www.tangosol.com/

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 21, 2007 10:38 AM
Reply to this message Reply
> Wow, that is a very good analogy!

Thanks Cameron. I thought the interview was a little thin. It seemed like it just ended abruptly. Did you have to run off somewhere?

Does this have anything to do with YAGNI? I personally feel pretty strongly that YAGNI is a good philosophy but my interpretation of it is at odds (I believe) with some other popular interpretations.

Perhaps my way of thinking is that we don't have to be YAGNI xor forward thinking but that we should be YAGNI and forward thinking. In other words these are forces that balance the design process. OK, I'm going to get a little DAO on you now. It's when these two forces get out of balance that the design goes into a tail spin (not that these are the only two things to consider but I'm not ready to write my manifesto yet.) If you go too far into trying to predict the future and get off track, YAGNI can pull you back into reality. If your blinders are on too tight, starting to think about some likely things that might be hard to deal with almost allows you to see the design with hindsight.

Does this make sense in your experience?

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 21, 2007 10:49 AM
Reply to this message Reply
Yes. If you try to predict / prevent everything bad and unexpected, you'll never write the first line of code.

OTOH, If you don't bother thinking it through, you'll end up writing that first line of code many times ("there's never time to do it right, but always time to do it over".)

Peace,

Cameron Purdy
http://www.tangosol.com/

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 21, 2007 8:15 PM
Reply to this message Reply
> OK, I'm going to get a little
> DAO on you now.

That should have been 'Tao'. I don't want to contemplate why I wrote 'DAO'.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 22, 2007 10:04 AM
Reply to this message Reply
> > OK, I'm going to get a little
> > DAO on you now.
>
> That should have been 'Tao'.

> I don't want to contemplate
> why I wrote 'DAO'.


Because it's the data that matters??? Not that I have any use for the melieu from which DAO sprang.

An oh-by-the-way observation: coders tend to *still* think of data the way their grand[m|p]as did in the 1950's; "I can always clean it up in a subroutine". That way lies perdition. Dr. Codd showed us the Promised Land. Smart data/dumb code beats smart code/dumb data any day of the week.

Describing a clean data model (the primary keys, in RDBMS speak) first will aid in understanding. As attributes (columns...) accrete, they have no impact on the system, since they're just along for the ride.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 22, 2007 12:35 PM
Reply to this message Reply
> Because it's the data that matters??? Not that I have any
> use for the melieu from which DAO sprang.
>
> An oh-by-the-way observation: coders tend to *still*
> think of data the way their grand[m|p]as did in the
> 1950's; "I can always clean it up in a subroutine". That
> way lies perdition. Dr. Codd showed us the Promised Land.
> Smart data/dumb code beats smart code/dumb data any day
> y of the week.
>
> Describing a clean data model (the primary keys, in RDBMS
> speak) first will aid in understanding. As attributes
> (columns...) accrete, they have no impact on the system,
> since they're just along for the ride.

Well, thanks for that random tangent.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 22, 2007 2:59 PM
Reply to this message Reply
> Dr. Codd showed us the Promised Land.
...
> Describing a clean data model (the primary keys, in RDBMS
> speak) first will aid in understanding.

For a contrary view see

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

So long as you are thinking in tables and key's, and others (like me) are thinking in objects with behaviours, we are in trouble.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 22, 2007 5:51 PM
Reply to this message Reply
> > Dr. Codd showed us the Promised Land.
> ...
> > Describing a clean data model (the primary keys, in
> RDBMS
> > speak) first will aid in understanding.
>
> For a contrary view see
>
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Comput
> er+Science.aspx
>
> So long as you are thinking in tables and key's, and
> others (like me) are thinking in objects with behaviours,
> we are in trouble.

Boils down to primacy: do you believe that the data structure can be defined in a robust manner in a robust transactional engine; or do you believe that data is hand-maiden to code?

Let it go at that.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 22, 2007 6:53 PM
Reply to this message Reply
> Boils down to primacy: do you believe that the data
> structure can be defined in a robust manner in a robust
> transactional engine [..] ?

For many applications, the relational model was quite sufficient in the 1980s, when an application might have only had a few hundred tables.

In 2007, a single object may map to a few hundred tables. One can no longer use the term "primacy" when the prima facie complexity of the prima is no longer in within an order or two of magnitude of the origin of the term prima ;-)

While the relational model may live on unabated underneath any new invention we could propose, it is not a model that can carry the weight of modern complexity on its own.

Peace,

Cameron Purdy
http://www.tangosol.com/

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Tangosol's Cameron Purdy on the Importance of Design Posted: May 23, 2007 6:41 AM
Reply to this message Reply
> So long as you are thinking in tables and key's, and
> others (like me) are thinking in objects with behaviours,
> we are in trouble.

I'm pretty sure I'm way out on my own here but I don't think of Objects and tables as being two facets of the same thing. More and more, I write application logic as not caring where the data comes from or goes to.

In other words, I don't map tables to Objects or vice versa. I drive my code with data. When that data is in a database, I drive my process with queries.

I do believe that a lot of people look at the database as a fancy file for persisting their Objects and if that's really what it is, it seems logical to move to an OO database. In my current situation, the database is a Database and data is king per the nature of our business. Code comes and goes but the data is forever. Mapping tables to objects doesn't really make sense in this situation. The problem to solve is how to use the data in the most robust and effective way, not how to get it into Objects. I believe you and I have discussed something along these lines before, Morgan.

Anyway, I guess the relational vs. OO argument seems artificial to me and both sides tend to be partisan.

Just to be clear, I don't mean to project any position on you or anyone else in this thread. I'm just rambling and not arguing against any particular points that have been made.

Flat View: This topic has 12 replies on 1 page
Topic: BEA's Nasir Khan Explains SIP Previous Topic   Next Topic Topic: Real-Time Garbage Collection

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use