The COBOL Problem
slott-softwarearchitect.blogspot.com
slott-softwarearchitect.blogspot.com
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
I get that he's trying to make the point that the software is complex with his statement. But how much does that really matter? Code can be really complex in a single line. And if the line count does matter, how are they counting the lines of code? Lines used in dependencies and third party libraries would probably make up a good amount of the total code, which may or may not have been written by engineers at Medtronic.
Maybe this is a pointless comment, but these kind of metrics irk me and remind me of my days at a major bank when they measured productivity by number of commits.
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.
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.
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.
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).
OOP was intended to solve this problem (at least in a single application) by restricting the mutation and access of the data to a single class. Given a monolithic server model it worked.
It is something that many of the modern programming languages completely fail at. Particularly the async oriented ones where its frequently possible to attach routines which mutate the state of an object from pretty much any point in the codebase. Combined with shared database access models/microservices/etc and systems get complex to the point where it takes real effort to logically map out all the individual parts which can read and modify a piece of data.
So in a way the current model is very similar to the mainframe batch processing model, where a bunch of fairly small standalone "jobs" ran to perform limited functions. Instead today, we have event triggered micro-services. With all the same problems.
You need to have a culture where people are allowed to become familiar with what is in their files and databases, and make sure they pass that knowledge on to others. Ideally in writing, but make sure it happens.
Too many developers assign more meaning to this year’s code than is really justified.
We need a git repo for requirements and business decisions, with pull requests and approvals, integrated with the main code repo.
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?
I do appreciate how it seems oddly more compact than most “Enterprise!” java code - e.g. copy books vs beans. How many times we gotta name the damn field to use it?
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.
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.
FWIW I work nowhere near management and I love Java, it’s easy to use and you can do pretty much anything you want with it. I say this as a middleware developer - there’s really no other platform than the JVM that I would like to use, and while I could spend months learning Kotlin or Scala or Clojure I could also just take the easy, lazy road and use Java. It’s not cutting edge, but I don’t need cutting edge. I need stability and as many actively developed libraries as I can to make my job as easy as possible. YMMV, but it’s not really fair to paint Java as a dinosaur that is loathed by non-management types, that’s just not true.