Imagine you’re tasked with renovating an old house but don’t have the blueprints and can’t employ the help of a structural engineer. While putting in countertops and floors, you discover that you accidentally tore down a load-bearing wall and cracked the foundation.
In a sense, this is sometimes what it’s like to be a software engineer. A 45-year-old discipline, software engineering 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’s surprising that the same programs that enhance our lives are in many cases so complex that no one understands them — and when programmers edit the code to add new features or change existing ones, the software breaks.
Computer science professor Nenad Medvidović of the USC Viterbi School of Engineering studies software architecture and seeks to bridge the 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,” he said.
So how does this happen? It’s due to something Medvidović calls design decay or architectural decay, a very common occurrence in the lifespan of a software program.
An average software program gets built by a handful of programmers for a very specific purpose. Years later, as the original software engineers have since left the company, a new batch of authors enter the code and make edits and updates. They add new code and remove code they think no longer is needed — they often use the software for things it was never intended to do. During these 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?” Medvidović asked. “How can we get to the point where we can help an engineer?”
Medvidović recalls helping a corporation deal with a problematic industrial machine. Software controlled the move of every intricate motor in the device. The code was more than 10 million lines long, built over a very long time by scores of revolving engineers. They had changed, deleted and added so many elements that the design of the system was unrecognizable, and no one understood how to fix it when something went wrong.
Medvidović watched as engineers used trial-and-error, shot-in-the-dark approaches 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, Medvidović said.
He 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.
“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,” he said. “That is what we mean by architectural design.”
Returning to the home renovation metaphor, Medvidović plays the role of the structural engineer: He can help a designer install that indoor swimming pool without bringing the whole house down.
More stories about: Faculty