When 2016 CS alumnus Ayush Narayan signed up for COMP 410, Software Engineering Methodology, he expected to learn design patterns and how to create a large system. Instead, he learned how to start over. “It taught me that software design is consistently watching projects fail and building them back up from the shattered remains of the past,” he said.
CS Professor Stephen Wong has introduced real world problems in the course for over a decade. There are no lectures. He introduces the client and the problem, then instructs the two dozen students to “organize themselves” into a cohesive software development team and solve the problem by the end of the semester. This spring, a global oilfield services company asked for a weather-aware logistics solution to decrease downtime.
Narayan, who was elected to one of the six team lead roles, learned that software engineering and people engineering were equally important. He said, “As a team lead, I was learning how to manage people, find what they are good at, and organize them into a cohesive unit.” He discovered a direct correlation between the quality of his team’s outcome and how well he organized and communicated with his team and with other teams.
“We experienced different kinds of failures,” said Narayan. “Our original design was pretty bad and we missed the point entirely. In other iterations, we couldn’t integrate things into our system smoothly, or the way we achieved our goal was too difficult to ever replicate.” He described several other project issues, including the selection of a service that was neither fast enough nor robust enough to handle their data stream.
He said, “When you realize your numbers are not high enough or that you can’t integrate it where you need, you tear it down. Maybe you were trying to fit a square peg into a round hole. It’s just not going to work, so you’ve got to scrap it and start over.”
One of his team’s greatest frustrations came at the half-way point. Narayan said, “Our use case had changed along the way, and one of the database systems we were trying to use just didn’t have enough storage. We had a solid infrastructure in place at that point, and we just had to start over.”
The leadership team also asked CS Professor Scott Rixner for a critique of their product at the half-way point. “Rixner promptly tore it down, like he usually does,” Narayan said, “and we found that we’d focused too much on scheduling.” He said there were known algorithms for scheduling, so the team should have looked instead at the enormous size of the data. “What we provided would only handle a small stream of incoming data,” said Narayan, “not a million data points per second.”
He chooses a positive outlook when he considers the series of failures his team experienced over the course of the semester. “Every step of the way, every small problem makes you more prepared to take on the next small problem. Projects are just an infinite stream of small problems to solve.”
Through the frustrations, Narayan discovered his own capacity for success. “I ran for database team lead, because I was terrible at databases and I wanted to learn more.” His penchant for tackling obstacles head on has paid off. “I’m going to be working in cloud infrastructure at Microsoft, and databases will likely to be an important part of my job.”