my thought would be to do iterative+incremental development, keeping
the scope as mind-bogglingly small and constrained as possible, to get
a core that is really solid, and to use extensive testing to help
increase the likelihood that it really is solid. and to get real
external users as quickly as possible, to help guide the evolution of
the system. furthermore, to publish as much information in the way of
test results and coverage, so that external folks can be reassured
that getting involved is worthwhile.

any thoughts on that or other approaches?

(like, why do so few people take a sane approach?! :-)

sincerely.

any thoughts on good interview questions which can help determine (as
much as any interview question can) if the interviewee has experience
with / the mindset for good simplicity? investigating their
understanding of design patterns would presumably be good. but i'm
currently musing over something more like: Here's some code, how would
you re-write it? (and hope the first thing they say is "try to make
sure the code has test coverage, first.") and look for them to be
moving in a good refactoring direction.

assuming systems need to be flexible; i think code often must have the
relationships among instances rejiggered, and that rejiggering can
lead to complex spaghetti relationships of refs all over the place.
those relationships can be hard to properly maintain with regular code
(at least imperative).

i find myself wondering if a more flexible approach might be the way
to go, and i think of relational databases (or actual relational
algebra, perhaps, as opposed to just the 'sql' style of relationships,
but that's a side nuance). would it possibly be a good approach in a
highly dynamic environment to use some db-style control of
relationships rather than more 'hard-coding' explicit refs among
instances within the instances or collections?

i wouldn't want it to allow a complete free-for-all, i've personally
experienced several bad to really awful database schemas, so i think
the idea needs to be implemented carefully. would use of db-style
constraints (one could draw analogies with unit tests) be sufficient
(along with good developer intentions and practice and process)?

sincerely.

many thanks for the thoughts. i also admit to very much needing to
expand my own understanding of these approaches, so such sample
interview Qs are great help for me to study & grok The Way.

sincerely.

Sent from my Verizon Wireless BlackBerry

I am new to design patterns and recently read the design patterns
explained book and it has brought up tons of questions related to how
to fix these into how I work today.

Wondering if anyone knows of a Study Group or User Group related to OO
and design patterns in the Seattle area?

Database relationships and their cardinalities are merely reflections
of the domain model.  Thus, in a system where the developers have a
poor understanding of the domain (or the domain itself is immature),
it is indeed likely that the relationships will change in nature over
time, as the domain model becomes better understood.

It is fairly easy to add new relationships, but it is significantly
difficult in a mature system to change the cardinality of
relationships.  This is because relationships are never DRY - they are
implicitly and explicitly repeated throughout a software system.

IMO it is a wild goose chase to spend time trying to generalize
relationships so that you can have flexibility later on.  If you do
not understand your domain, you are better off building one or more
versions of the system to throw away.  In that way, you learn more
about the domain, and the relationships naturally stabilize.

On Wed, Sep 10, 2008 at 1:00 PM, Raoul Duke <raould@...> wrote:
> assuming systems need to be flexible; i think code often must have the
> relationships among instances rejiggered, and that rejiggering can
> lead to complex spaghetti relationships of refs all over the place.
> those relationships can be hard to properly maintain with regular code
> (at least imperative).
>
> i find myself wondering if a more flexible approach might be the way
> to go, and i think of relational databases (or actual relational
> algebra, perhaps, as opposed to just the 'sql' style of relationships,
> but that's a side nuance). would it possibly be a good approach in a
> highly dynamic environment to use some db-style control of
> relationships rather than more 'hard-coding' explicit refs among
> instances within the instances or collections?
>
> i wouldn't want it to allow a complete free-for-all, i've personally
> experienced several bad to really awful database schemas, so i think
> the idea needs to be implemented carefully. would use of db-style
> constraints (one could draw analogies with unit tests) be sufficient
> (along with good developer intentions and practice and process)?
>
> sincerely.
>
>



--
Steve Campbell
http://blog.perfectapi.com/

Just came across something that Thomas Edison said that tweaked my
thinking a little:

<quote>
...Edison said some years later to Mr. Upton, his mathematical
assistant, that "he always considered he was only working from one
room to another. Thus he was not confused by the amount of wire and
the thought of distance."
</quote>

Edison attributed at least part of his prolific genius to his ability
to abstract problems.  Weinberg in his work on Systems Thinking
pointed out that part of Newton's genius was his ability to abstract
away and ignore the gravitational pull of everything except the pull
between each planet and the sun.

Often as I work, I tend to "ignore" things as I program. This becomes
a problem though when I work with what I call an "old school
programmer"... one who believes in defensive programming.  They want
to cover every possible case of every possible call to every possible
method.

For my part, I only want to cover the path that is accessible by the
external user of the system. So if I have a method in the database
layer that would blow up if a NULL was passed, but I know that given
the view layer validation it is impossible to get in that state, I am
unlikely to test for NULL or care if it will blow up.

So, for you guys who have been doing this a lot longer than me, am I
following the path of genius by ignoring things?  Or am I following
the path of the lazy by not covering my bases?  Sometimes I feel like
the latter!

Matt

P.S.  Note that in one Edison experiment, he passed a signal through
2200 miles of stored underwater cable.  Instead of printing a dot 1/32
of an inch long, it printed a 27 foot dot!  He "ignored" the fact that
the wire was coiled and got bit by the fact that coiling increases
induction.

Scott,

--- In leanprogramming@yahoogroups.com, "Scott L. Bain" <slbain@...>
wrote:
>
> Fowler essentially said your mother was wrong when she said "never put
> off 'til tomorrow what you can do today", rather he says to put off
> everything you can because you'll be smarter tomorrow.
>
> The key to his idea is "everything you can".  Some things are better
to
> ignore until you have more detail; many of them will change anyway.
> Some things are critical up-front; these form the primary abstractions
> in your domain model.
>
> -S-

So what about when you reach "done-done-done" for a story"?  Acceptance
tests are all running and you are ready to move on to the next one...

That is usually the point where I get the "well.. what if someone calls
this method and passes in a null?"  My response has always been "well,
they will get a broken test".  Part of me says this is perfectly fine,
but part of me wonders if the code would be better if we wrote a unit
test and made sure the method wouldn't break with a null.

So I could put that off until tomorrow.. but should I?  Is there a way
to tell when you cross the line from "flexible code" to "weak code"?

Loved your book by the way.. thanks.

Matt

Mel,

--- In leanprogramming@yahoogroups.com, "Bartels, Mel" <Mel.Bartels@...>
wrote:
>
> >>>
> So, for you guys who have been doing this a lot longer than me, am I
> following the path of genius by ignoring things? Or am I following
> the path of the lazy by not covering my bases? Sometimes I feel like
> the latter
> <<<
>
> There's a right time to worry about dbnulls and lots of wrong times to
worry about dbnulls.  One 'ignores' issues while developing software
(gosh, what happens if bad in put is passed in?) because one is
concentrating on building out the core, one and only responsibility of
the entity or object.  Some people jokingly call this 'lazy'.  I call it
'smart thinking'.   BTW, I consider the best way to handle dbnulls is to
use a nullable pattern or objects.  Then the issue never comes up.
>
> Rocket scientists get paid to lighten the rocket; we (ought to) get
paid to remove code, simplify the design, and look for commonality
(symmetries).
>
> Mel Bartels

Funny you should mention the nullable pattern...  I just solved a
problem with that this week and it's a thing of beauty in my opinion! :)

I like the analogy with lightening the rocket... thanks.

Matt

hi,

> versions of the system to throw away. In that way, you learn more
> about the domain, and the relationships naturally stabilize.

thanks for the note! that sort of experienced perspective helps a lot.

thought experiment / beating a dead horse / straw man: could there be
any utility in making everything many2many, and then using constraints
to turn those into lesser cardinalities, so that when one discovers
the need to revise it isn't the whole schema that has to change? maybe
in other words: where can one draw the line between conceptual model
and implementation, and how can one most flexibly set up the
implementation to not be restrictive yet also not be vapidly
unconstrained at the model level?

i might be thinking and writing gibberish.

sincerely.

> the need to revise it isn't the whole schema that has to change? maybe
> in other words: where can one draw the line between conceptual model

p.s. point being that even if i am going to build one to throw it
away, i suspect it would not be optimal to "just freaking hard-code
everything, man!" while i'm making that. because there are fractal
levels of change happening, and you don't want to have to throw
everything away for the smaller types of change.

maybe it all, as folks have already said, just comes back to hitting
the books and practicing up on design patterns.

sincerely.

Scott,

--- In leanprogramming@yahoogroups.com, "Scott L. Bain" <slbain@...>
wrote:
>
> The problem with "what about this?" is that there is really no end to
> it.  Amir says every test should create a unique distinction, and it
> should reflect something you intend.
>
> For instance, if I am testing that algorithm X produces a 5 when you
> give it a 9, I suppose I could write a test that ensures it does not
> erase all the files from my root.  I mean that's possible, right?
>
> -S-

I agree.  I like the "something you intend" qualifier... it fits my
mental model of design.

Any suggestions on how to nudge defensive programmers in the right
direction?  They seem to want to program for everything... intended or
unintended just to make sure.  But like you said... where does that
stop? :)

I ask for suggestions because presumably someone on this list *used to
be* a defensive programmer and now views the world a different way.

Matt

>> The problem with "what about this?" is that there is really no end to it.

not that many people have the choice, but choice of programming
language can be a significant factor. e.g. Haskell helps ensure
nothing else can happen.

sincerely.

hi,

>> Any suggestions on how to nudge defensive programmers in the right
>> direction? They seem to want to program for everything... intended or
>> unintended just to make sure.

> Remove the project dynamic that's causing them (in their best judgement) to
> write excessively defensive code?
> Pair them with testers at the lowest integrated testing level to help them
> see where they should concentrate their efforts?

i tend to be one of those paranoid sky is falling types. i think i am
often justified because i do not think sufficient thought and effort
has been put into making a principled and over-arching error handling
system. folks just sort of throw exceptions here and there, and sort
of catch them there and here, and i often don't see a really good
rhyme or reason.

if i were working in a system that i knew was structured properly for
errors, then i would be more willing to worry less about random
things.

so i'd suggest having a good error (and logging) architecture. :-)

sincerely.

----- Original Message -----

From: Raoul Duke

To: leanprogramming@yahoogroups.com

Sent: Wednesday, September 17, 2008 11:47 AM

Subject: Re: [leanprogramming] flexible data relationships?

hi,

> versions of the system to throw away. In that way, you learn more
> about the domain, and the relationships naturally stabilize.

thanks for the note! that sort of experienced perspective helps a lot.

thought experiment / beating a dead horse / straw man: could there be
any utility in making everything many2many, and then using constraints
to turn those into lesser cardinalities, so that when one discovers
the need to revise it isn't the whole schema that has to change? maybe
in other words: where can one draw the line between conceptual model
and implementation, and how can one most flexibly set up the
implementation to not be restrictive yet also not be vapidly
unconstrained at the model level?

i might be thinking and writing gibberish.

sincerely.

> Here are some things that have worked for me, YMMV.

Many thanks to all for the thoughts! The point of starting simple
(flat file) and only introducing complexity (rdbms) when you really
need it and really think you grok why, sounds very sensible.

I must apologize for not better explaining what was in my head,
probably, though, d'oh; It is something I read in Dr. Dobbs a long
time ago and thought was sort of crazy, but has since started to seem
more... tempting. It is perhaps done with DInjection instead these
days, but the idea was to have indirection in your (i think it was C++
in the article) program between instances and refs among them. So
instead of instance A having a pointer to instance B, even for has-a,
it would go through an explicit lookup table which would later let you
muck with the cardinality for example. OK, that sounds like a stupid
idea the way I say it now... but the overall idea/question is
something like: how do we write software that lets us most easily (so
we are happy devs) and safely change the graph of relationships?

apologies if this still makes no sense outside of my own head (and
maybe even inside it as well).

sincerely.

> apologies if this still makes no sense outside of my own head (and
> maybe even inside it as well).

one aspect of my nebulous thought is sort of along these lines:
http://osdir.com/ml/lib.boost.devel/1999-09/msg00116.html

sincerely.

> BTW.  As a defensive programmer, do you get annoyed that you are almost
> forced to create getters and setters for all of your member variables?  I
> hate it when I create an object that only needs a few getter methods, but to
> serialize it I have to create getters and setters for everything.  However,
> I can say that I like how in C# you can serialize private member variables
> or properties using the DataContractSerializer.

hm, only $0.02, but I think what is even worse about all that whole
"get/set" approach is that it means mutable objects, which tends to
lead to sloppy control of state, which tends to lead to bugs. like,
even in languages which give you automatic getters/setters (Scala on
the JVM, or whatever), I still don't like having mutable objects. so,
yeah, it kinda kills me how the boilerplate is insult to injury. :-}

sincerely.

P.S.: dang, sorry, didn't read closely enough and missed the whole
"serialization" aspect.

On Wed, Sep 17, 2008 at 10:05 PM, Raoul Duke <raould@...> wrote:
>> BTW.  As a defensive programmer, do you get annoyed that you are almost
>> forced to create getters and setters for all of your member variables?  I
>> hate it when I create an object that only needs a few getter methods, but to
>> serialize it I have to create getters and setters for everything.  However,
>> I can say that I like how in C# you can serialize private member variables
>> or properties using the DataContractSerializer.
>
> hm, only $0.02, but I think what is even worse about all that whole
> "get/set" approach is that it means mutable objects, which tends to
> lead to sloppy control of state, which tends to lead to bugs. like,
> even in languages which give you automatic getters/setters (Scala on
> the JVM, or whatever), I still don't like having mutable objects. so,
> yeah, it kinda kills me how the boilerplate is insult to injury. :-}
>
> sincerely.
>