Re: Saving the System i: Fight Rather Than Switch -- MIDRANGE-L

I think that programming itself will change inherently. With moreplug-n-play software (sure, read SOA), there will be less coding and moreorchestration and choreography. And while we might take thehave-a-go/fail/have-another-go/fail/have... approach to orchestration andchoreography, I do think that more disciplined approaches are needed if weare actually using a business approach to IT.


Maybe my standards ARE too high.

Oh well, back to SEU for me!

----- Original Message -----From: <AGlauser@xxxxxxxxxxxx>

To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, December 15, 2006 2:46 PM
Subject: Re: Saving the System i: Fight Rather Than Switch

Trevor Perry wrote on 15/12/2006 03:16:28 PM:

First, I did not imply anything - let alone that an IDE can prevent

logic

errors.


Well, that seems to be how at least a few of us read your statement.

 Which leads me to believe that your approach is simply
undisciplined.


I don't understand how this follows, although I do agree that many shops
(including mine) do not follow disciplined software development models.

What happened to code walkthroughs?
Did they go out of fashion because we got a faster server?


I've only been at this for a couple of years, so I guess I got to the game
after they went out of style.  I think that walkthroughs would be a great
idea.  The problem is that many shops have so many projects piling up that
it's difficult to make the case for a more methodical approach, because on
the surface it appears that such an approach would take more time per
program.

I just think that we have it easy - the System i works well serving

multiple

tasks - production AND development. And we got lazy in our coding

efforts. I

used to teach a class called "Programming for performance and
maintainability". What I found was code that was hard to read by the
programmer who WROTE it - and maintainability was improved by several
things. One was better documentation (IN THE code) - WDSc helps with

this,

because you can see it clearly and can see MORE of it. Another was

spending

time understanding the code before diving in and

edit/compile/edit/compile -

with the ability to see more of the code, more source members, and tools

like verify, WDSc helps us be better programmers.


I love WDSc too, but as I'm sure you are well aware - "there is no magic
bullet".  Software systems tend to be complex, and I while I agree that
more disciplined coding and software lifecycle approaches can lower the
rate of bugs in new code, I still think that the "compile, test, fix"
cycle will be with us forever.