Re: Tangling "AS/400 Education" and "Design shift" threads -- MIDRANGE-L

Scott,

I went to a CC.  Not because I really wanted to, but at the time (1971) there
were no 4 year universities that would let me create my own curriculum.  My 
major
was Business Administration and ALL of my electives were design/programming
courses.  Because I was unwilling to pay for a quarter of studying 19th century
English authors (mandatory), I forwent my degree and pursued an education
instead.

Giving that up freed me to take whatever courses benefited me the most.  At
whatever institue that offered what I needed.

In talking to the admissions counselor I termed my curriculum as "applied
technology".  I also had a mentor.  My goal was to out do him.  That took a lot
more work than the work required at the CC.

If I had attended a 4 yr. university and been a Computer Sciences major I may be
a better coder, but I'm not sure that I would have been a better designer.  IMO,
one must fully understand the problem at hand, along with the tools available, 
in
order to create an effective solution.

Small digression: There was a thread asking about a Payroll application
recently.  The majority of the responses recommended outsourcing.  My company
licenses more copies of Payroll than any other single application.  This left me
wondering, did the outsourcing proponents have experiences with a Payroll
application designed by people ignorant of labor laws, union contracts, the 
whims
of governmental agencies?  Did they design in a modular fashion?  Was the 
ability
to adapt the software one of their design criteria?  From my viewpoint, Payroll
is one of the easiest applications to design because the decisions are out of 
the
hands of the user.  There are a whole lot less "it depends" kind of answers then
in designing let's say a credit/collections application.

But back to the point at hand, education.  IMO, the best teaching method I know
of is the "case study" method used at Harvard.  Along with teaching how to code,
how about taking an application/program and dissecting it to understand why
certain choices were made and the cost/benefit of it and any alternatives.  Take
those choices into context of the environment/industry of the installation.  
Then
change the environment/industry and test to see if the decisions still hold
water.  Or introduce a new technology like thin clients, JVM's and then ask if
the design is still the "best" design under any given criteria.  Rearrange the
importance of the criteria then ask again.  My economics instructor did this.  
On
the first day he stated that if we wanted to know how to calculate return on
investment, go look it up.  He was going to teach how to make choices.  In all 
of
the exercises there were no "right" answers.  We were graded on how well we
supported the decision.  BTW, the debating also taught a little about human
behavior. <g>

Hopefully it would teach that the "right" answer is what is right within context
and that there may be more than one "right". This may stop the holy wars of a
particular technique (can we say DOx <g>) and develop an atmosphere where
creative solutions can be accepted.

James W. Kilgore
qappdsn@ibm.net

"Programs  ARE data." - anon.


Scott Cornell wrote:

> Never being one to be shy, I'll risk confusing issues :)
>
> <<all the really good stuff>>
>
> Preparing to be flamed by CC graduates, but still curious as to the
> opinions out there
>
> Scott Cornell
> Mercy Information Systems



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---