Meet new faculty: Gregory Gay, computer science, engineering
Posted on: September 22, 2015; Updated on: September 22, 2015
Name: Gregory Gay
College/department: Computer science and engineering
Title: Assistant professor
Degrees: Ph.D. in computer science, University of Minnesota, 2015; M.S. in computer science,
West Virginia University, 2010; B.S. in computer science, West Virginia University,
2008
Hometown: Morgantown, W.Va.
What’s your area of study or research?
My research is in software engineering. Most computer science disciplines focus on building software for particular domains. An artificial intelligence researcher invents new ways to use software to model thought processes. A data-mining researcher will develop software to find patterns in large bodies of information. Software engineering is the study of software itself — how we build it, and importantly, how we can be better at building it.
Our society is built on software. It powers our homes, it manages our private information, it controls our cars, it automates our factories and — through advances in medical device technology — it even regulates our bodies. It is incredibly important that we become better at constructing robust, operational systems, especially given growing demand for features, limited development budgets and strict time constraints. My work largely focuses on making this happen through improvements in how we test software, particularly through better methods of automating the testing process.
Why did you choose Carolina?
My fellow faculty members here seemed supportive of each other, clear about what they wanted out of their department and both interested in and excited about the work that I do.
What are you most looking forward to this year?
Getting to know my new town, settling into my new department and starting to work with some great students.
What are you most looking forward to about being at in Columbia and South Carolina?
Being able to wear shorts in the winter. Did you know that Minnesota gets down to -40 degrees? I'm going to be grilling in flip-flops here in January.
Also, delicious barbecue. And hushpuppies. Mmm …
Oh, and – again – working with some smart, passionate students.
How did you become interested in your work?
This is going to be a little morbid, but I learned that bad software can kill people. Software problems have led to rocket explosions, helicopter crashes, radiation poisoning and — relatively commonly these days — identity theft.
In other engineering disciplines, the real-world impacts of product design are pretty clear. If you design bridges or electrical generators or cars, you know what to do to protect people. That isn't as clear when you build software, since software is entirely intangible. Figuring out how to support safe development is an incredible challenge and one that keeps my brain spinning.
What made you decide to go into academia?
Teaching is an incredibly rewarding experience. There's nothing like hearing from someone after they take your class and they tell you that the things you taught them were actually useful for something.
Having the opportunity to advance the state-of-the-art in how we build software, and then turning around and using those tools and techniques to prepare students for working as software designers and engineers is a fantastic opportunity.
What’s a talent you have or something that you’ve done that people might find surprising?
I play a mean game of Tetris.
What do you hope to accomplish over the next five years?
Jet packs and flying cars.
Seriously, though, I'd like to have a nice little research group built up, full of smart students doing great software engineering work. I'd like to have some industrial partners who are putting our work to use and are feeding data back to us to improve our techniques. That sounds like a good place to be in five years.
What was your dissertation?
Something boring and long-winded.
When you test software, you need something called an “oracle.” This is just some code that you have in place that checks whether the software gave you the output you expected. If 2+2 should equal 4, then the software should spit out 4 when you ask it to add 2 and 2. It takes a huge amount of time to come up with a result by hand for every test — you might have thousands of them (in practice, for this very reason, people use a dozen tests when they should use hundreds). So, building an oracle that works for anything is quite hard.
One promising method would be to build a basic model of how the system should work and use that as your oracle. Teams that design software where the risks of failure are high — airplane designers, medical device companies — sometimes build these simplified models before they create the actual software as a type of blueprint. In theory, we could use these models as oracles. See if the software output matches the model output. In practice, this doesn't work well for complicated systems because the models have been simplified. They don't take into account things like complex timing behavior. If the model did all of that, it wouldn't be a model — it'd take as long to build as the real system and wouldn't work for development.
My dissertation proposed an automated framework that can adjust the behavior of the model to better match the behavior of the system being tested to account for these complex situations. This behavior adjustment — called model steering — is controlled by a set of constraints (defining the differences in behavior that are acceptable between model and system) and is based on a search process attempting to minimize a dissimilarity metric. This framework allows nondeterministic, but bounded, behavioral differences, while preventing future mismatches by guiding the oracle — within strictly defined limits — to match the execution of the system.
See? Long-winded and boring.
Learn more
To learn more about areas of study in computer science, visit the College of Engineering of Computing website.