Re: Productivity
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 28 Dec 2006 14:34:05 +1300
Really good response, Daniel. Thanks.
Comments below...
"LX-i" <lxi0007@xxxxxxxxxxxx> wrote in message
news:73e30$4592adbc$454920f8$28313@xxxxxxxxxxxxxx
Pete Dashwood wrote:
But despite all of that, it is quite obvious that my productivity in
Visual Studio 2005 is MUCH better than my productivity using the Fujitsu
IDE.
This impressed me when I first started working with VB6 many years ago.
What I found especially useful was that it syntax-checked each line as you
typed it. I wrote a VB program to parse our DMS schema and compute card
columns. I looked at it a few years ago, when I already had some years of
VB experience under my belt - it was horrendous! But, it was
syntactically correct.
I really scorned VB for many years seeing it as being "kiddie programming".
Fortunately, I was forced to use it to modify a Rational tool, and this
caused me to appreciate how powerful and concise it is, and to re-adjust my
attitude.
VB6 is a full blown programming tool and deserves its place in my toolbox.
A little over a year ago (or has it been 2 now - wow!), I used it to strip
the data items and create relational tables. Now, the code is much
tighter - and to calculate the total size of an OCCURS clause, I just read
ahead in the dataset to get all the PIC sizes, and multiply by the number
of times.
It is ideal when you need something in a hurry...:-)
This made me think about tools.
VS 2005 provides an Interactive Development Environment that is simply
years ahead of any other development environment I have ever worked in
(on both mainframes and PCs).
Colour coding of code, rollaway windows that you can pin down when you
want them or send to a tab when you don't, intuitive context sensitive
tooltips, having all your defined variables available for selection at
the moment you want to reference them, having all methods, events and
properties for the object you are referencing available as you type,
along with help tooltips for any you select, ...all of these things
collectively add up to MAJOR productivity improvements.
SlickEdit (formerly "Visual SlickEdit") does many of these things for
COBOL, although not to the extent that VS2005 does for C#. Our
productivity shot through the roof when we began using it for our COBOL
code development. It will pop up a list of variable defined in working
storage, has context-sensitive help, and even has a window that will show
you the definition of whatever variable the cursor is on. (All this
assumes you have the thing configured correctly - it will build "tag
lists" for the COBOL COPY libraries, for example, but you have to do that
for the feature to work.)
It's a little pricey, IMO, for an editor ($200 last I checked), but of
course, the US taxpayers provide us our copies. :)
I never heard of SlickEdit, but it sounds good. I don't think $200 is a lot
to pay for a useful tool...I'm staggered that MS simply GIVE Visual Studio
2005 Express away...I guess they can afford to and it certainly gets people
into their camp.
Back in 2002, I was out at Oracle in Silicon Valley, at a week-long "hey,
pick us!" pitch they were giving the USAF. Some of the folks there were
from the Software Engineering Institute (SEI) at Carnegie-Mellon
University. One of the ladies there saw it open on my laptop and said
"Hey, is that Visual SlickEdit?" I told her that it was, and she said,
"we use that all the time for our Java! I never would have thought to use
it for COBOL." I thought that was kind of funny because, at the time, I
had never thought of using it for Java.
It's funny (and interesting) how we are blinkered by what we know...:-)
But.most importantly of all, the environment is NOT focused on code
development. It is pure event driven programming. You DON'T start by
writing IDENTIFICATION DIVISION (or its equivalent). You design what you
want and the code for the events is placed into the right contexts for
you. All of the housekeeping, fixed context, and overhead is hidden
(unless you WANT to see it). You focus totally on your application and
what you want to happen when events occur in it.
This follows from the component based approach. Thinking in "functions" (or
"production line machines"), encapsulated pieces of functionality that are
stable and robust, is a really good way to develop applications. We get too
tied into code. Need to get data and start thinking about READ...AT
END...NOT AT END... etc. when we should be thinking about WHAT we are
getting, WHY we are getting it at this point, and at how many different
places we are going to need to get it, and providing a function that simply
gets it.
I believe the difference between procedural and non-procedural approaches
underlies this. COBOL programmers are used to a sequential procedural
approach with rigid control and event driven programs aren't like that.
Objects lend themselves to being used anywhere at anytime so design can be
much more flexible.
I don't really have a good comparison here, because our COBOL is based on
the Unisys mainframe. I do know that there are tools that really
integrate Windows with it (such as the ability to map drives to mainframe
program files, interactive debug execute on the mainframe from the PC).
Of course, none of them have been approved for use. (Don't get me started
on that...)
So, it looks like I will be winding down my COBOL development.
The tools for cutting edge development are MUCH better and cheaper than
COBOL. It remains useful for batch development, which is what it was
invented for, and where we came in...
And what it's still used for in our environment. We're seeing thousands
of batch jobs run per day - in fact, we recently had to change the way we
handled these runs, because the users were literally bringing the system
to its knees. (Have you ever seen a mainframe beg? It ain't pretty...)
Now, we have a controller, and we're actually clearing more runs than we
did with the old way, because we're controlling the number that are
started.
Yes, COBOL is excellent for sequential batch processing and will fill that
requirement for some time to come. Eventually, transactions will be
processed so fast that Batch will not be necessary, even reports will be
spooled online as transactions occur, and so there will be less dependence
on Batch. Only historical reporting would need a batch approach. But that
time is still a few years off yet.
That's the one thing that I'm not sure about - there still is a need for
innovation within the COBOL community. There are processes that are
crucial for businesses and governments that cannot be replaced
immediately, but could be improved. What happens to these apps as the IT
world "moves on"? I don't see improvements - in our arena, every system
we interface with has had big problems with a fraction of the transaction
volume that we clear on a slow day. There was one recently that went to
30-plus second response times when they got 4 users! Then, you deal with
all these policies and things that you have to deal with to be
"compliant," and they all seem to suck bandwidth and performance. Sure, if
you're running on a huge box, it'll be passable - but are the network
folks giving us funds to upgrade our hardware? Heh.
A very good point. I suspect that rather than fix or improve, these systems
will simply be allowed to atrophy until they are replaced. If the
replacements, as you describe above, are far worse than the existing systems
then they simply should not be accepted until proper SLAs are agreed and put
in place.
For good or bad, the above won't be my concern for the system on which
I've worked for the past 9 years. In a way, I hate that, because I have
so many other ideas that I know would improve the system with minimal
investment of code. I guess I just have trouble detaching myself from
this thing that I've worked so hard on for the past 9 years.
If you didn't care about it you wouldn't be much good at it :-)
We all get emotionally attached to things that have been a big part of our
working life, even though we know we shouldn't.
why don't you write a paper on the system, outling some of the areas that
could be improved , and suggesting some approaches so that anyone taking
over at least has the option, based on your years of experience, to
implement some of your ideas?
Even if they don't, at least you know you gave it your best shot.
Probably more than you wanted to hear... :)
Not at all. I for one, found your observations interesting.
Those are some of the thoughts I've had about productivity.
It's something that many of us should give some thought to...
Pete.
.
- Follow-Ups:
- Re: Productivity
- From: Howard Brazee
- Re: Productivity
- References:
- Productivity
- From: Pete Dashwood
- Re: Productivity
- From: LX-i
- Productivity
- Prev by Date: Re: Productivity
- Next by Date: Re: Variable Length Input File
- Previous by thread: Re: Productivity
- Next by thread: Re: Productivity
- Index(es):
Relevant Pages
|
