Developing new software is not only technically challenging but also requires an understanding of how people will adopt it, says Dr Wolfram Schulte, former director of engineering at Microsoft, at the recent IEEE/ACM International Conference on Automated Software Engineering (ASE 2016).
Back to Research@SMU Issue 41
Photo Credit: Rebecca Tan
By Rebecca Tan
SMU Office of Research & Tech Transfer – Whether you are reading this article on your desktop or mobile phone, you are relying on software that converts a string of zeros and ones into shapes that you can understand as words. All this happens seamlessly—most of the time—so much so that we only notice software when it doesn’t function as it should. Behind the scenes, scores of engineers build, troubleshoot and release new software and updates, helping us navigate the digital world with ease.
But just because their labour is unseen by the layman does not mean that the work of software engineers costs nothing. For companies like Microsoft where software is a source of revenue, the value that the software creates needs to be measured against the amount of work that it took to create the software. In short, productivity matters.
“Whether it is automatic test case generation or developing better build systems, what we strive for is improving productivity,” said Dr Wolfram Schulte, former director of engineering at Microsoft’s Developer Division. “To quote our CEO Satya Nadella, ‘There cannot be a more important thing for an engineer than to work on the systems that drive our productivity.’”
Schulte was addressing the crowd at the IEEE/ACM International Conference on Automated Software Engineering (ASE 2016), held at the Singapore Management University (SMU), Singapore from September 3-7, 2016. The yearly event, now into its 31st edition, is attended by software engineering researchers the world over and aims to help them advance the field of software engineering by building automated tools to improve productivity and software quality.
Mind-boggling complexity
Building a complex piece of software begins with the developer, who edits, compiles and runs the code he or she writes on a desktop before submitting it for review. Once the code has been officially approved, it has to be verified in the system the code is designed for before the software can be released to the users.
While this development cycle might seem straightforward for a simple project, building software such as Microsoft Windows or Office each involves more than 100,000 projects, with each project description requiring between 10 to 100 lines, Schulte explained.
“That’s ten million lines of code just for the description on how to translate program sources into executable binaries. On top of that, there’s build logic written in different languages, which adds a few million lines of code and which uses more than a thousand different tools,” he added.
To add to the complexity, software builds are typically worked on by thousands of developers at a time, each contributing changes that have to be merged into the official code. “There are literally thousands of check-ins into the version control system for Windows or Office every day,” Schulte said.
Many hands make light work
Microsoft’s solution was to develop CloudBuild, a build service infrastructure that takes advantage of distributed computing or cloud computing. Instead of executing instructions on a single machine, distributed computing breaks the problem up into smaller ones, solving them on multiple computers working concurrently. However, moving to the cloud is not without its problems.
“When we build software sequentially, everything is fine. But as soon as you start building concurrently or incrementally, things get off track because builds are no longer reliable,” Schulte said.
To solve the issue of incrementality, the CloudBuild developers used highly optimised caching strategies. A cache speeds up computation by storing the result of a previous computation, allowing users to call on the cache instead of repeating the computation.
Beyond the cloud
However, some software is just too complex, to move simply to the cloud. The group working on Windows, for example, generates more than one petabyte of build-exhaust per day. “We would clog up the public internet if the Windows team would have to transfer this amount of data 24/7,” Schulte quipped.
Instead of CloudBuild’s more gradual evolutionary approach, a more revolutionary change was needed, he said. Schulte’s solution was to develop a new build language, which by design guarantees reliable and efficient builds. Adopting the new build language improved Windows builds in important scenarios by up to a hundred times. However, getting there was far from easy.
“In the end, I think the revolution failed. While Windows is adopting the new build system, adoption is slower and happens in smaller increments than initially expected,” Schulte confessed.
“As a researcher, I take bold bets and what I wanted is for people to adopt my revolutionary ideas fast. Turns out, that only works if you built a new product. If you have to improve something as big as Windows or Office, only an evolutionary approach works because there are so many people working on the system concurrently while you are changing it.”
“What we learned was that ultimately, this is not only about technology; it is also about working with people,” he added, highlighting the differences in mindset that sometimes exist between researchers and practitioners.
“Conferences like ASE go a long way in helping bring both groups of people to the same page,” said SMU’s Associate Professor David Lo, general chair of this year's conference. “Even people who are not from an information systems background can benefit from the high levels ideas presented here.”
“More and more apps are being developed, be it for handheld devices or running on the cloud, and there is a lot of work needed to improve developer productivity and software quality. We hope that conferences like these will make more people interested in advancing software engineering,” Prof Lo concluded.
Back to Research@SMU Issue 41