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?

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.

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

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/

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

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/

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

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

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

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

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

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

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