These days, the energy buzzing around Marouane Kessentini, associate professor of computer and information science, is hard to miss.
On a recent October afternoon, it came in the form of a visit to his lab from two people from eBay. One was a former Ph.D. student whose work in the lab helped him land a job as a senior scientist at the online shopping giant, and the other was an eBay recruiter there to scout the new talent about to emerge from Kessentini’s farm team.
Earlier in the month, the excitement took shape as yet another big-deal honor for the 34-year-old faculty member: The University of Michigan’s Office of Technology Transfer announced his software refactoring tool — which helps automate the process of cleaning up messy legacy code — as one of eight notable U-M inventions of the year.
With more than 500 inventions coming out in 2018, it wasn’t for lack of competition. Kessentini was also the only UM-Dearborn professor to earn a nod.
Tech Transfer’s Drew Bennett said Kessentini’s work in the field of refactoring stands out for several reasons. For starters, his tools have broad application throughout industry (it is, after all, hard to think of a company that doesn’t use software), and they’re already being licensed across the market.
But perhaps most impressive is that up until recently, effective refactoring tools were seen simultaneously as both a ‘holy grail’ and ‘lost cause’ in the field of software engineering.
“I would absolutely agree that he’s kind of rescued this field,” Bennett said. “Big companies spent a ton of money on trying to solve these same kinds of issues 10 or 15 years ago. But the technology just wasn’t quite there, and ultimately the tools in this area just haven’t proven very effective.”
Part of the reason for that is that the basic problem refactoring aims to solve — what’s known as “technical debt” — is broad, systemic and constantly evolving. It stems from the very practical challenge that businesses and organizations that depend on software are constantly having to fix bugs, add new features and improve their code.
When new code is introduced, however, the solutions can be far from elegant — usually because of time pressure. And after this process is repeated hundreds or thousands of times, the overall code can evolve into a giant, tangle of ad-hoc solutions that make future improvements increasingly more difficult.
Like interest on credit card debt, the messiness accumulates over time until it starts to feel more like a fact of life than something one can ever get out from under.
In fact, Kessentini said as much as 60 percent of a typical programmer’s time can be spent manually wading through the maze of past fixes — before they even get around to implementing a solution for a particular trouble ticket. That costs companies time and money, and can be a real morale drain for employees who’d rather be doing something more creative.
The beauty of Kessentini’s refactoring system is that it automates much of the process.
It starts with a diagnostic tool that combs through the code, identifies problems, sorts them into categories, ranks their importance, and then — most significantly — suggests a pre-fab solution for programmers. If they see it as a good fix, all it takes is a couple clicks to automatically implement the solution. What used to take hours, now takes just minutes or less.
The weekly Spotlight features faculty and staff members at the university. To nominate a candidate, email the Record staff at [email protected].
Moreover, Kessentini’s tool uses machine learning to improve its suggestions over time. It even has the capacity to suggest a curated list of fixes for a particular programmer who, say, may have skills or history or preferences for working on certain kinds of issues.
In short, over time, the tool learns who likes to work on what. Kessentini said one can think of it like the list of suggested products one gets based on past internet search history.
“In fact, one of the new things we’re working on is a solution to what’s called the ‘bugs localization’ problem,” Kessentini said.
“When we talked with companies, many of them told us that when they receive a call from a customer to report an error, and a ticket gets submitted to the programmers to fix it, they’re spending up to two weeks to fix errors — simply because the ticket isn’t finding its way to the right person quickly enough. It might get passed around a team, but no one takes it, because they think it’s someone else’s area.
“So our tool uses the description in the ticket and the problematic code to automatically find the right person to solve the issue.”
