Quizz : What kind of COBOL dev are you?

You must add (or subtract) a certain number of days from a given date:

R1 - Let's go, within a loop, testing number against end-of month, if greater, go to next month and subtract number of days added from original number and start over until remaining less than end of month. Wait! number can be negative? Oh no!

R2 - I have my own routine I carry along with me from jobs to jobs.

R3 - I use the (I don't know how it works) routine provided by the company, written by the numerous generations of COBOL devs that went before me - it was a nightmare to figure how it works.

R4 - I develop that routine others use but don't know how it works using UNIX 1904 or EXCEL 1900 standard (based on a switch) even if I know about XL1900 bug for Feb the 29th 1900.

From how many lines you duplicate would you prefer to go for a specific paragraph that factorize code?

R1 - What is factorization?

R2 - 5 lines of code replicated deserve a specific paragraph

R3 - I follow specifications of the company if any, otherwise it depends on my mood.

R4 - 1.

How would you calculate the effective length of a string -meaning without the trailing spaces? (Assuming string and length are the names of your vars)

R1 - this code:

MOVE 0 TO length
PERFORM UNTIL string (length:2) = ' '
OR I >= LENGTH OF string
ADD 1 TO length
END-PERFORM

R2 - like this, more?

PERFORM VARYING length FROM LENGTH OF string BY -1
UNTIL length = 0
OR string (length:1) NOT = SPACES

R3 - I use copy provided by company:

COPY AnExistingStrlenCopy REPLACING ==:LENGTH:== BY ==length==
==:STRING:== BY ==string==.

R4 - I put the following code into a copy for I can COPY REPLACING it as above:

MOVE 0 TO :length:
INSPECT FUNCTION REVERSE(:string:) TALLYING :length: FOR LEADING SPACES

What is your opinion about code review?

R1 - What is code review?

R2 - My code does the job, no need others to tell me how to do!

R3 - I will comply with the company standards, even if I esteem it is time wasting.

R4 - Code review is mandatory to ensure horizontal integration and ease further maintenances.

You must bind the processes of your program according to the values of some variables that come from records you read.

R1 - I test the value of the variable against hardcoded values before each process.

R2 - I set some 88-levels when reading data and test against these 88-level when necessary.

R3 - I set a standard parameters file where I code values and expected behaviors for I can easily change the general program behavior just by changing parameters.

R4 - Same as previous, by the parameters are set in a special copy I can call “a component” and I can instantiate at will, and parameters are available either thru a file or a DB access depending on a switch set at runtime.

Business asks you to implement a computation rule based on an amount less than or greater to 50€.

R1 - I code:

IF AMOUNT LESS THAN 50 THEN
process A
ELSE
process B
END-IF

R2 - I set a variable in working with value 50 and test against that variable

R3 - I set 50 as a parameter into a standard parameters file and test against the parameter automatically retrieved in the program.

R4 - I set 50 into a parameters application where business can access the value at will and change it itself (according to some security rules, of course). In the program, a copy retrieves params, then I test against the parameter.

What is the best PICTURE clause for an amount?

R1 - 01 AMOUNT PIC 9(6).

R2 - 01 AMOUNT PIC S9(9)V9(2).

R3 - It depends on how other amounts are coded into the program I'm working on

R4 - Embedded in a copy:

55 :AMOUNT:-VALUE PIC S9(11).
55 :AMOUNT:-NBDECS PIC 9.
55 :AMOUNT:-CURRENCY PIC X(3).
55 :AMOUNT:-ASFLOAT PIC S9(9)V99.
55 :AMOUNT:-ASSTRING PIC X(15).

You answered most R1: You are the dinosaur.
You are in the loop for ages, you spent many years in a single company and took all their usages. You do not question yourself about relevance or quality of what you are coding. When a bug occurs in your programs, it occurs at numerous places, because you duplicated code. However, you can locate and fix it easily. When you'll leave the company, your knowledge will also vanish, causing nightmares to your heirs. However, you always worked like that, therefore the way you work MUST be the good way of working.

You answered most R2: You are the cowboy.
You spent all your professional life as a contractor, moving from one company to another, and this defines your own way of working. You acquire the way you develop COBOL through various experiences, and your strong mind extract the quintessence of COBOL. Your code is strong and clear but is very bad at taking upgrades. However, you would not question yourself anymore, therefore the way you work MUST be the good way of working.

You answered most R3: You are the chameleon.
As the cowboy, you were carried along many companies during your professional life, but you always tried to adapt to procedures and specifications of each company, never questioning them. Even if you find these procedures heavy and useless, they -for sure- were written for good reasons, so you must follow them. Therefore, the way you work MUST be the good way of working.

You answered most R4: You are the alien.
You are the nightmare of all IT managers, ever questioning them on the purpose of any rule, proposing something else you guess more relevant or efficient. You solve by yourself many common problem and offer innovative and elegant solutions. The point is that you did it three different kinds in three different companies. Once you leave a company, other devs abandon your code, because they can't figure out how it works, despite the documentation you left. Anyway, you strongly challenge your colleagues, and your solutions are always quick, 100% working and evolutive, therefore the way you work MUST be the good way of working.

Hope no offense was taken from reading these profiles, it was not the intent. However, I'm pretty sure many of you recognize several traits that are yours.

The point of this exercise was to make you realize you might strongly be convinced you are good devs, that you use good practices. However, this believe is often seen from a single point of view.

We are often supposed to work within teams and with several stakeholders, each of them having their own priorities.

We all must learn to work together with clear rules and well-defined procedures. However, never hesitate to regularly question these, because the world evolves, and what makes sense today might be totally irrelevant tomorrow. Never forget the monkeys experience.