Eric Raymond Shares 'Code Archaeology' Tips, Urges Bug-Hunts in Ancient Code

Open source guru Eric Raymond warned about the possibility of security bugs in critical code which can now date back more than two decades -- in a talk titled "Rescuing Ancient Code" at last week's SouthEast Linux Fest in North Carolina. In a new interview with ITPro Today, Raymond offered this advice on the increasingly important art of "code archaeology".
"Apply code validators as much as you can," he said. "Static analysis, dynamic analysis, if you're working in Python use Pylons, because every bug you find with those tools is a bug that you're not going to have to bleed through your own eyeballs to find... It's a good thing when you have a legacy code base to occasionally unleash somebody on it with a decent sense of architecture and say, 'Here's some money and some time; refactor it until it's clean.' Looks like a waste of money until you run into major systemic problems later because the code base got too crufty. You want to head that off...."
"Documentation is important," he added, "applying all the validators you can is important, paying attention to architecture, paying attention to what's clean is important, because dirty code attracts defects. Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."
For a final word of advice, Raymond suggested that it might be time to consider moving away from some legacy programming languages as well. "I've been a C programmer for 35 years and have written C++, though I don't like it very much," he said. "One of the things I think is happening right now is the dominance of that pair of languages is coming to an end. It's time to start looking beyond those languages for systems programming. The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore... think it's time for working programmers and project managers to start thinking about, how about if we not do this in C and not incur those crazy downstream error rates."
Raymond says he prefers Go for his alternative to C, complaining that Rust has a high entry barrier, partly because "the Rust people have not gotten their act together about a standard library."