How To Deal With 200k Lines of Spaghetti Code

An anonymous reader writes "An article at Ars recaps a discussion from Stack Exchange about a software engineer who had the misfortune to inherit 200k lines of 'spaghetti code' cobbled together over the course of 10-20 years. A lengthy and detailed response walks through how best to proceed at development triage in the face of limited time and developer-power. From the article: 'Rigidity is (often) good. This is a controversial opinion, as rigidity is often seen as a force working against you. It's true for some phases of some projects. But once you see it as a structural support, a framework that takes away the guesswork, it greatly reduces the amount of wasted time and effort. Make it work for you, not against you. Rigidity = Process / Procedure. Software development needs good processes and procedures for exactly the same reasons that chemical plants or factories have manuals, procedures, drills, and emergency guidelines: preventing bad outcomes, increasing predictability, maximizing productivity... Rigidity comes in moderation, though!'"

Comments

200K Lines not that much

[PerlPunk]

I have spent most of my career as a software developer inheriting and updating such spaghetti code bases. Here are few remarks and some of my experiences around this:

1. 1) 200K lines is not such a formidable size. If your average module size is 1000 lines of code, that's 200 separate modules. Or if the module size averages 2000 locs, that's 100 modules. Gradually getting your head around the modules is not as big a problem as it seems, even if there are many interdependencies between modules. However, if the average module size is something on the order of 10K or 20K, then you really are dealing with spaghetti code, and that's quite a bit harder to figure out than if the module size on average were around 2 or 3K.
2. 2) For the time being, treat the whole application like a black box, which means not worrying too much about how well it works until you have to fix some "bug". At that point, figure out how it works only insofar as you need to in order to get your bug fix in, and record your lessons learned in a wiki and in comments in the code. Refactor as you go along, if feasible.
3. 3)Being able to step through code is really helpful when trying to understand a poorly documented code base--even if the code is well structured. A number of technology platforms (like Java JVM) offer remote debugging.
4. 4) You can reverse engineer these things and produce a set of business specs with which to port the application to a new platform. Right now, I'm on a project that is porting 125K lines of COBOL code that ran on OS2 to an Apache/mod_perl technology stack. Our team consists of 2 cobol developers, who are producing the specs from the code, and 3 perl developers who are porting it. The key here is to capture the business requirements and the user interface behavior. Once you do that, how you implement it on the new platform is quite straightforward. HOWEVER, this approach is not advised unless your company or gov enterprise has lots of time, deep pockets, and a commitment to seeing the project through to its eventual success.

In summary, don't be too scared of a legacy spaghetti code base. These things can be understood well enough in time to refactor or port to a new platform.