
The COBOL Problem - smitty1e
https://slott-softwarearchitect.blogspot.com/2020/04/the-cobol-problem.html
======
java-man
"Software is a form of knowledge capture. If the language (and tools) have
become opaque, then the job of knowledge capture has failed."

I would add that "the job has failed". The next consultant who modifies the
code is destined to break it (resulting in more work required of said
constractor, so we have a dangerous incentive here).

Just today, Medtronic CEO boasted that their ventilator uses 1 million lines
of code. How much of this is the test code? Can requirements be traced to the
code and code to the requirements?

Another example: how many projects on GitHub provide a comprehensive list of
requirements/features? If you don't have a traceable list of requirements you
_don 't know_ what you are building (or testing). And, on your job: how many
projects you worked on that have a comprehensive list of requirements?

[0]
[https://twitter.com/Medtronic/status/1245777861774118913](https://twitter.com/Medtronic/status/1245777861774118913)

~~~
lliamander
> Just today, Medtronic CEO boasted that their ventilator uses 1 million lines
> of code. How much of this is the test code? Can requirements be traced to
> the code and code to the requirements?

I have friends that used to work in the medical device industry. Processes
there are pretty strict, so it might very well be the case that they do.
However, 1 million lines of code is _a lot_ so I would still be worried about
bugs.

> Another example: how many projects on GitHub provide a comprehensive list of
> requirements/features? If you don't have a traceable list of requirements
> you don't know what you are building (or testing).

That's a bit different. That's usually people scratching their own itch.

> And, on your job: how many projects you worked on that have a comprehensive
> list of requirements?

I don't know that a comprehensive list is what is valuable. What is valuable
is being able to explain the provenance of a particular piece of code. The
best way to do that is with version control. With version control, you can
usually figure out why the specific piece of code was written either because:

1\. The commit referenced an ticket in a work ticket database

2\. The commit has an explanation for the change in the commit description

3\. The commit contains a code comment or a piece of documentation that
explains the change

I think many people assume that they need a separate master database of
requirements, and so only (1) is valid. However, whenever I've had to do
maintenance on a piece of legacy code, the version control system has been my
most reliable source of truth.

Of course, a lot of these old mainframe systems were built before proper
version control techniques were developed. Revamping them is going to benefit
greatly from advances in those techniques.

~~~
java-man
Speaking of the version control. You are right: VC is indispensable tool when
looking at an old (hm "mature") code base, assuming the said code base has not
been converted from CVS or SVN, with commit comments like "merged from branch
XX".

I still think the value and importance of recording every last
feature/functionality is underestimated in the industry. Granted, the tools to
support this idea are largely missing - the requirement tracking must be
integrated into VC and the workflow, it should have powerful search and
pattern matching (this change was due to REQ#, also relevant REQ#, REQ#,
REQ#...)

Imagine you have a controlled and non-intrusive way to document all the
features. What value does it add?

1\. Testing. A feature set automatically generates the skeleton of a test
plan. Test cases that are missing from the feature list get added to said
feature list.

2\. Onboarding. The feature list is a great place to study for a new team
member.

3\. Development. Given the pattern matching, the feature list might suggest
related areas where a change might have unexpected impact - in addition to the
usual code inspection tools, of course. The code answers the question of how,
the requirements answer the question of why.

4\. Maintnance. The requirements change. Assumptions and design decisions
change with time. If you don't have a record of those, you have no idea why
this code does what it does.

P.S. and I fully agree with what you said for other points.

~~~
Roboprog
Saving the revision history from the previous source control system would
require reading the manual or Google for 20 minutes. I got deadlines!

Of course, if the previous system is a proprietary monstrosity, it may well be
next to impossible to recover the history short of writing a script to check
out every step along the way and duplicate it in the new system. Ugh.

Anybody who went down the path from RCS - CVS - SVN - Git without saving the
check in / commit history is being a bit of a jerk, though.

------
Roboprog
I got a laugh out of the ad at the bottom of the page: “convert COBOL to
Java”.

I mean, it’s the first thing that went through my head when I saw the article,
but...

We got off of that 60 year old language, and are no longer beholden to IBM!

... to be on a 30 year old language (that few outside of management love), and
owe our souls to Oracle.

Yeah, balancing stability and ease of use is hard. The post-Java landscape is
pretty fragmented with many more developer friendly options, but it’s hard to
know what will still be well supported in 20 years. I like JavaScript - which
is also as old as Java, but seems to have aged better - but I understand that
it scares the hell out of many developers.

So what do we replace COBOL _with_?

~~~
core-questions
> So what do we replace COBOL with?

Why replace it at all? Why not build up GnuCOBOL, and evolve the needed IDEs,
deployment infra, and mainframe functionality replacements around it, so we
can continue to use old, functioning code in new ways?

Insisting on rewriting the code is insistence on simply never completing the
project at all.

~~~
skissane
A lot of COBOL software is running on IBM mainframes under z/OS. In that case,
it isn't just COBOL, it is all the middleware and OS components the COBOL
interacts with – CICS, IMS, DB2, VSAM, JCL, DFSORT, etc, etc, etc. Duplicating
all of that functionality is an infeasible task. Duplicating a big enough
subset that you can successfully port a real world mainframe app is
achievable, and a number of commercial offerings exist which do that – e.g.
Oracle Tuxedo Application Runtimes for CICS/IMS/Batch, Tmaxsoft OpenFrame,
UniKix, etc. However, building such a solution is a huge amount of work
requiring a rare skillset, and I doubt the open source community has the
ability/resources/motivation to replicate that work.

~~~
Roboprog
I hear that. I worked at a place in the early 90s that had a product to port
System/36 based RPG II code onto newer platforms. It kept 4 of us pretty busy,
and RPG is just a small language doing flat files on a mini with a simple
scripting language (OCL = operation control language) and job queue system.

Later we took on the AS/400 version, but I left before that product went live.

I can’t imagine how much IBM’s mainframe system has sprawled out over the last
quarter of a century.

