Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> “And in practice, five, ten, okay, fine. 10,000, no, we're done. It is not safe, and I don't need to see all 10,000 global variables to know that that is a problem,”

At an old job, my boss asked me to take a look at a business critical application to see if it could be improved upon. It had some deficiencies that were really hampering things.

I got the source from a coworker (this is when I worked on rockets, so none of us were or are professional software people, but even my dumb engineer self knows this is not how it should be). I opened up the folder. Lots and lots of files with little apparent structure. Ah, there was a file called "MAIN". I opened it. Visual Basic 6. Over 29,000 lines for global variable declarations alone. The actual program logic heavily used a commercial library designed to (shudder) make VB6 development more like making macros in spreadsheets. The original programmer then implemented the main program logic in this hellish abomination. The logic took up another 50,000 lines or so.

I told the boss that it would be easier to write a new program from scratch then attempt to understand it.

Has anyone seen a program with more globals than this?



I once worked for a billion dollar retail company. Their core back office applications (sales tracking, logistics, orders and fulfillment, staff rosters, etc) were written in COBOL and the inputs and outputs were read from / written to temporary files; kind of like pipes but via temp files in case of job failure. The real problem was that there were about 3,500 COBOL programmes and 2,500 shell scripts all in one directory. All the executables, COBOL and shell alike, were given a 4 digit filename; there was no up to date documentation on what program did what (apart from the source), or in which order they should be run, or the dependencies there in. To top it off end of day processing would take between 12 to 16 hours to run; any major problems and it would start affecting the next day's EOD. There was only one guy in the office (who had been there 15 years) who understood how it all fit together; when he died things got much worse (no he wasn't that old, how he died is another whole war story all together).

I only lasted there 6 months before I left for a start up, in many ways it was too much to bear. A while after I left taxation for retail changed substantially, there was a massive IT stuff up and the billion dollar business wound up being carved up and sold off; several thousand jobs affected, many lost their jobs either directly or indirectly as a result.

Sure this is probably at the worst end of the scale (short of causing deaths) and is rare but it does happen. Billion dollar company succumbs largely because of IT failures. It got to the point that the cost of the technical debt was higher than the carve up losses...


To the grand parent: you're not supposed to look at generated code, if you have changes you're supposed to re-generate it. So at some level, that's the 'why' that happens.

In Cobol 85, all variable are global to the program, and statically allocated at program start up. It's not uncommon for a Cobol program to import 10's or 100's of 'copybooks' and have 100-1000's variables in the global scope. They are, however, name spaced after a fashion.

My experience with this came from a similar behemoth mainframe app; 35 MLoc, 15,000 programs, thousands of jobs, running a batch and interactive green screen app that a company hosted. Was the source of about $500M a year in revenue.


>To the grand parent: you're not supposed to look at generated code, if you have changes you're supposed to re-generate it.

Generated code? What do you mean? (I have no familiarity with VB6 at all. I have written quite a bit of code in C, Python, and MATLAB). Besides, all this was handwritten (I eventually had a conversation with the code's original author while at a party). The guy was crazy enough to write all of that by hand. I genuinely think the effort made him a little unhinged.

And of course he could have been lying...


"Generated code? What do you mean? (I have no familiarity with VB6 at all."

I think the parent is referring to generated COBOL code.


Sounds like you need to submit this to DailyWTF...


Nowhere near as many, but I had to deal with this very recently and this little WSJ gem showed up:

https://github.com/ewfelten/Tracking-Report-Card/blob/master...

I'll let the code speak for itself.


That looks like autogenerated code. That's a different beast altogether.


It is. Mozmill is a testing framework. What we're looking at there is a file containing automated tests (which I think should be fairly obvious to someone looking at that file...)


I'm well aware of what it is. Like I said, I had to deal with it recently - I didn't just pull it out of thin air.

What you're looking at is a horror beyond comprehension. There's much better, more maintainable ways to write automated tests.


I guess we'll have to disagree, especially about this part:

> horror beyond comprehension

"Horror"? No, but I guess that's debateable (apparently). But "beyond comprehension"? Absolutely no. Even if we say the repetition offends our aesthetics, I can't even imagine what sort of issue you had to deal with where this file posed a problem. Anything you could possibly want to do with it should be serviceable inside of 5 minutes, except in the dumbest of Notepad-quality (i.e., little more than a text control) editors. That includes rewriting the whole thing to be less offensive, if that's your slant.

This file is nothing compared the types of things mentioned upthread, things which, again, exist in a context of actual production code.


If that is horror beyond comprehension then you are a very, very lucky person. The auto-generator even indents the code nicely!


That's not bad at all - it's a lot, it's not DRY and it could be reduced to about 25 lines of code (or 25 + the number of URLs to check), but it's legible, clear, and easy to understand.


It's a strange feeling when some small webdev are using clean modular testable code while real life businesses are abusing VB in creative ways. Really makes me feel paradigms do matter. My last job involved a huge pile of VB (VBA to be exact) code and again, it was an unstructured mess.


Yes, just about every damn PHP project I inherited that wasn't bound to a framework, or wasn't an existing OSS project.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: