Logo: University of Southern California

Frankencode

How software falls apart and USC Viterbi Professor Neno Medvidovic helps put it back together
By: Katie McKissick
October 30, 2013 —

Imagine you are tasked with renovating an old house, but you aren’t given the blueprints and can’t employ the help of a structural engineer. While you’re putting in granite countertops and bamboo floors, you discover that you accidentally tore down a load-bearing wall, cracked the foundation and burst a sewer pipe.

In a sense, this is sometimes what it’s like to be a software engineer.

Software engineering is a 45-year-old discipline, and it has changed our lives for the better in countless ways. Today, software programs run everything from computers and mobile phones to cars and airplanes.

Given the advances and utility of software engineering, it may come as a surprise that these same programs that enhance our lives are in many cases so enormous and complex that no one understands them, and when programmers edit the code to add new features or change existing ones, the software breaks.

Professor Nenad Medvidovic in the computer science department does research in software architecture; he seeks to bridge this gap between software programs and the people working with them.

“Shockingly enough, there are many companies out there that sell products where very few, if any, of their engineers actually understand how those products are built any longer,” Medvidovic explained.

How does this happen?

It’s due to something that Medvidovic calls design decay or architectural decay. It’s a very common occurrence in the lifespan of a software program.

At the birth of an average software program, it gets built by a handful of programmers for a very specific purpose. Years later, the original software engineers having since left the company, a new batch of authors enter the code and make edits and updates. They add new code. They remove code they think they no longer need. They often use the software for things it was never intended to do. During the changes, a foundational element in the code breaks, and the program no longer works quite right. Like Frankenstein’s monster, it’s spinning out of control.

“How can we deal with this mind-boggling complexity and size?” asked Medvidovic, “How can we get to the point where we can help an engineer?”

Medvidovic recalls visiting a large corporation to help them with a software problem they were having with a large industrial machine. Software controlled the move of every intricate motor in the device. The code was over 10 million lines long, built over a very long time by scores of revolving engineers. They had changed, deleted and added so many elements, the design of the system was unrecognizable, and no one understood how to fix it when something went wrong. He watched as engineers tried trial-and-error, shot-in-the-dark style to fix the machine. They changed one line in the code and ran a test. It didn’t work. They then changed a number in a different line of code and tried again. On and on they went until the machine seemed to work.

Temporary patches and circumstantial fixes like this aren’t uncommon. But it doesn’t have to be this way.

“What we’re trying to do is cluster the software into meaningful components, so your 10,000 software modules result in 150 high level components,” said Medvidovic. “That is what we mean by architectural design.”

Medvidovic and his team write software programs that analyze and interpret the code of massive existing software programs. They give stakeholders a blueprint for their software system, breaking it down into functional parts, and showing designers where the “load-bearing walls” are, and in which areas they have room to play with new features.

Returning to our home renovation metaphor, Medvidovic plays the role of the structural engineer. He can help a designer install that indoor swimming pool without bringing the whole house down.