What's the most unsound program you've had to maintain? [closed]

Answer 1

I maintained ExtUtils::MakeMaker. MakeMaker is certainly not the worst code I've had to maintain; it's actually an engineering marvel. However, it is in that unique class of coding horrors wherein the most mission-critical code is also the most terrifying.

MakeMaker is the installer for most Perl modules. When you run "Makefile.PL" you are invoking MakeMaker. If MakeMaker breaks, Perl breaks. Perl runs on everything, so MakeMaker has to run on everything. When I say everything I mean EVERYTHING. Every bizarre Unix variant. Windows 95 on up. And VMS. Yes, VMS.

What does MakeMaker do? Makefile.PL is a Perl program that writes a Makefile which contains shell commands, which often run Perl, to build and install a Perl module. Let me repeat: It writes shell commands to run Perl. Perl, the language which replaces shell scripts.

Oh, it can also compile and link C code. And it can also statically link Perl modules into perl. Oh, and it can manage RCS checkouts. Oh, and roll tarballs of your distribution... and zip files. And do all this other stuff vaguely related to installing modules.

And it has to do all this in a portable, backwards compatible fashion. It has to deal with variants of and bugs in...

• make (GNU make, BSD make, nmake, dmake, mms, mmk to name a few)
• shell
• Perl
• The filesystem (if you don't think that's a big deal, try VMS)
• C compilers & linkers

It absolutely, positively can not fail and must remain 100% backwards compatible.

Oh, and it has very little in the way of a real extension API, so it has to remain compatible with the ad hoc Makefile hackery people have to do to extend it.

Why does it do all this? 15 years ago when Perl only ran on Unix this seemed like a great idea. Why write a whole build system when you can just use make? Perl's a text processing language; we'll just use it to write a Makefile!

Fortunately there is a replacement, Module::Build, and I pinned my hopes that it would swiftly kill MakeMaker. But its uptake has been slow and the community very resistant to the change, so I'm stuck maintaining MakeMaker.

Answer 2

The one I have just started on.

1. No Source control.
2. All source is edited live. To stop mistakes, there are backup files like db-access.php.070821 littering the source tree.
3. The code is exceptionally brittle - there is very little in the way of error checking and absolutely no fall back if it does.

Answer 3

I used to be a COBOL programmer (shudder). All of our code fell into the "unsound" category. In COBOL, you have no namespaces, all variables are global and there's a lot of mandatory duplication of filenames and other resources. To call a procedure, you set global variables, call the procedure, and then inspect the contents of those global variables (or others that might get set).

The worst, though, was maintaining a COBOL program written before I was born (I was born in 1967) and its exclusive method of flow control was the GOTO. It was an absolute mess and impossible to follow. Minor changes to a variable type could take days to work out. There were no automated tests and manual test plans were never saved, so every change required a new manual test plan be written out, followed exhaustively, and turned in with the code.

Ironically, this is what makes COBOL so successful. COBOL is often executed by Job Control Language (JCL). Since COBOL is so weak, programs don't do a lot, so JCL would allocate some disk space (often down to the cylinder level), and execute a small COBOL program to read data and then write out just the data you need. Then JCL might call a sort program to sort the resulting file. Then another COBOL program would be called to read the sorted file and summarize the data and maybe re-extract the needed results. And maybe JCL would be used again to to move the file somewhere else, and yet another COBOL program would get called to read the results and store them in a database, and so on. Each COBOL program tended to only do one thing and a primitive version of the Unix pipeline model was created -- all because COBOL is too hard to maintain or do anything complicated with. We had loose coupling and tight cohesion (between programs, not in them) because it was almost impossible to write COBOL any other way.

Answer 4

I once worked on a CAD application written in BASIC where the company policy was that every program must begin with the statement:

ON ERROR RESUME

jMM

Answer 5

A PHP/MySQL-driven online contact management system, where the contact table did not have a natural key. There were numerous instances of database fields containing composite data in the form of a delimited string that subsequently needed to be parsed by application code.

The HTML and logic were intertwined, almost no functions were used, but rather code was cut and pasted into dozens of source code files. Data was not sanitized and so fields with (e.g.) embedded vertical tabs caused the XML returned by Ajax calls to malfunction, and to top it all off, files with dozens if not hundreds of empty statements consisting of closing braces immediately followed by semi-colons: "};"

Answer 6

The interpreter for a CAD/CAM geometry processing language (P1 = 10,10; P2 = 20,20; L1 = P1,P2; - that sort of thing), written in Microsoft BASIC Professional Development System (PDS), with minimal length variable names (it ran out of single letters quickly, so moved on to double letters. PP, PQ, PR, anyone?). And, to be fair, some comments. In Italian.

Funnily enough, it actually worked, and I was able to add some functionality to it, but it was like amateur dentistry - painful, and certainly not recommended...