Design Process

[Jason Marshall]

>On Tue, Jan 11, 2000 at 10:28:02PM -0800, Jason Marshall wrote:
>> I'm curious what design processes one uses on large functional
>> projects, and, more to the point,
>> how might one work within a 'metaprogramming' framework?
>> How do you divide and conquer?  Unit test?  Debug?
>> Interface to legacy code?
>I can't say, because I don't have that much experience yet.
>I guess it's almost like with other systems, except that
>in your design iterations, you also modify your development tools
>so as to adapt them to your needs.
>I think that language developers already do that kind of things;
>but in presence of non-reflective languages, they are "privileged" 
users.

I think it's a little too early then to dismiss such a strong design 
tool.
Refactoring isn't just about spackling over the warts of OOD.  It's the 
admission that you can't reasonably have a complete project design
set in stone before line 1 of the code is written.  It's just not going 
to
happen on many non-trivial projects.  There's too much ignorance about
what we really require to get a project done.  To some extent, among 
developers, but to a greater extent among management.  And even 
were that not the case, in any R&D project, you're going to be flying
by the seat of the pants anyway.  You won't necessarily know upfront
if something is really possible or not.  If it isn't, you may have to 
back
away from some prior assumptions, throw away or gloss over some
code intended to utilize the technique.

Alternately, most code is written because it doesn't currently exist in 
the
APIs.  If it was there already, it wouldn't be needed.  Certainly you 
don't
expect TUNES 1.0 to be the final form of the APIs (or perhaps more 
appropriately, the standard metamodel library).  So you're going to 
have
people developing their own models in parallel with other developers,
both in-house and through the standardization process  People will
come up with many similar-but-not-equal patterns, idioms, ideas.  And 
at some point they'll have to rearrange the rest of their code, in 
order
to use this new, standardized variation on their old theme, because
complimentary ideas prop each other up, and if you change one, the
other may suffer.  

In short, you're going to have lots of code with evolving models.  And 
if
the model evolves, then that means the metadata has as well.  TUNES
TUNES hopes to address by automating the process of any resulting 
code changes created by such modifications, but this automation still
requires something or someone more creative 'behind the wheel' to
keep everything on track.


Regards,
Jason Marshall