[Pdx-pm] Software development and The Rules

Jon Jacob jon at manymoons.net
Tue Sep 24 20:07:35 CDT 2002


Having not really studied the MVC method of software development, but
still interested in this discussion, I googled for MVC and Perl.  I
found one very interesting site, which gave some illumination on the
subject:

http://www.perl.com/pub/a/2001/10/17/etoys.html?page=4

(This was one among several, but this one specifically dealt with Perl.)

Now, earlier their was a generalized statement about "The Rules".  I am
not a big fan of rules per se.  I think there are guidelines, and some
of the guidelines work in some cases and some in others.  Sometimes, the
best guideline choices are based on personalities of the team and some
are based on project requirements and outlines.  That is just my
experience.

The MVC system sounds interesting, but it is one of those things that
makes me think that I have mostly being doing all along, maybe without
knowing it.  Now, I may not be clear on the complexities of MVC, but it
does seem very straight forward.  If I understand what it is saying, it
recommends a granulation of components along the lines of separation of
presentation (HTML in the case of CGI with templates), modeled by
processing code, and then controlled by a system that takes the
processing of the data and spits in out to the presentation part of the
system.

Again, I have not formally following the MVC guidelines, but that sounds
to me like what it does in a nutshell.  I can see how these would be
good "rules" to follow, but I don't see anything revolutionary within
that system.  To me, this is how your write and develop code, but not
how you create a system as a whole or how you get from soup to nuts.  Am
I expecting to much for this discussion?  Maybe so, but too often
prospective employers are asking how I handle things like QA and I have
no answer because in web development situations there seems no
stipulations for these sorts of things.  What I would like to know is
how QA and modelling done before and after the code is actually
written.  Too often, this is part of the software where things get
confused and bogged down.





More information about the Pdx-pm-list mailing list