Cobol Horror
-
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
-
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
maxxx# wrote:
but she wasn't a junior (and she never became a senior)
I bet after that she was not even employed anymore, was she? :P
Regards. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson Rating helpfull answers is nice, but saying thanks can be even nicer.
-
maxxx# wrote:
but she wasn't a junior (and she never became a senior)
I bet after that she was not even employed anymore, was she? :P
Regards. -------- M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you “The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson Rating helpfull answers is nice, but saying thanks can be even nicer.
Nelek wrote:
I bet after that she was not even employed anymore, was she?
Now she is the boss lover, I suppose. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
-
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
maxxx# wrote:
Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax
maxxx# wrote:
It contained a huge array of constants, called January1984, February1984 etc. etc. etc.
Dont you mean: JAN84, FEB84 ? ;P
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
maxxx# wrote:
Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax
maxxx# wrote:
It contained a huge array of constants, called January1984, February1984 etc. etc. etc.
Dont you mean: JAN84, FEB84 ? ;P
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
Probably - though I seem to rememebr a 32 character limit on field names in Cobol - so could have been the full month name and year
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
maxxx# wrote:
Probably - though I seem to rememebr a 32 character limit on field names in Cobol - so could have been the full month name and year
I was just making a Y2K joke :)
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
maxxx# wrote:
Probably - though I seem to rememebr a 32 character limit on field names in Cobol - so could have been the full month name and year
I was just making a Y2K joke :)
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
It is a good thing she did not try to take into account that years ending in hundreds area not, but thousands are. The control code would have been smaller, but the array would have had 12000 entries.
Silver member by constant and unflinching longevity.
-
It is a good thing she did not try to take into account that years ending in hundreds area not, but thousands are. The control code would have been smaller, but the array would have had 12000 entries.
Silver member by constant and unflinching longevity.
-
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
Cobol Horror Nuff said.
Deja View - the feeling that you've seen this post before.
-
I just found this board, and just had to share... A programmer had the job of writing a routine to perform calculations based upon fees over time (the detail's not important - essentially she needed to know the number of days between two dates, and apply an algorithm something like 'for the first 30 days, a fee of 10c per day, up to 45 days, 25c per day, from 46 through to 100 45c per day) Now, there's 1001 ways to do it - but I couldn't believe that she produced a huge Cobol program to do it. It contained a huge array of constants, called January1984, February1984 etc. etc. etc. wach one being the number of days in that month. Then she had an If FromDateMonth = "January" and FromDateYear = 1984 Subtract DateDay from January1984 Giving calcDays. Else If FromDateMonth = "February" and FromDateYear = 1984 Subtract DateDay from February1984 Giving calcDays etc. etc. for every month of every year for about ten years. THEN she repeated the same set of If's for the end date. THEN she repeated the same set of If's, in a loop, for each month in between! I couldn't believe that any programmer could be quite so dumb! When asked, she just said she couldn't think of a better way of doing it! (Oh, it had taken her nearly two weeks to do - I had estimated a day, and allowed her a week, as she was new to the company, though not to Cobol) And sure, I should have looked at the code before she got so far - but she wasn't a junior (and she never became a senior) (Oh and excuse my code - it's been a long time since I did Cobol and can't really remmeber the syntax)
Take a chill pill, Daddy-o .\\axxx (That's an 'M')
Cobol is horrific anyways :rolleyes:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
It does look like she was trying to be very through, so I am not suprised that she accounted for leap years. What this really points out is that it is not enough for a programmer to be able to write code that works; we also have to be able to come up with fast and efficient ways to solve problems. Bill
