5 minutes with Suzanne McIntosh
Software solutions for space systems? As part of this month’s Women in Data Science series, we catch up with Suzanne McIntosh, Clinical Associate Professor of Computer Science
Suzanne McIntosh is an Clinical Associate Professor of Computer Science at NYU, and an affiliated faculty member at the Center for Data Science. Situated in between academia and industry, McIntosh teaches computer science graduate and undergraduate courses while also providing consulting services for major organizations like IBM, where she worked as a technical team leader to develop technologies for virtualization, cloud computing, and big data analytics. She is an expert in the Hadoop and Spark ecosystems, has been the Lead Inventor of multiple patents, acts as an advisor to start-ups and as a STEM mentor at the New York Academy of Sciences (NYAS) and Society of Women Engineers.
1. You have gained experience in both academia and industry over your long — and very busy! — career. What are some of the strengths and drawbacks to both worlds, and what advice do you have for STEM students who are trying to decide which world they want to join?
I’ve had the honor of developing software solutions alongside engineers working in the defense industry on mission critical communications and space systems, developing base station software for commercial telecom, researching security, virtualization, and analytics solutions for targets ranging from tiny smartcards to green data centers, and now, joining the research community in academia.
Developing firmware for mission critical defense systems requires at the very lowest levels of software development and integrating with custom hardware, rather than off-the-shelf hardware. This means that even the hardware is new and untested, making the software development and testing process even more challenging — and debugging often means working with engineers from a variety of disciplines. It also requires quite a lot of process. While a lot of people tire of all the process involved in tracing requirements to implemented code to prove that all requirements are met and tested, process is what helped ensure the systems deployed were reliable and robust.
The advantage of working in such an environment is that it is humbling — the complexity of these systems, and the stringent requirements instill in these engineers a relentlessly methodical approach. Here we were very concerned that if a system was compromised, we needed to detect this within a very, very short timeframe and take steps to shut everything down in full to prevent any leakage of information.
Contrast that with the interest of commercial telecom, which was to keep the system going even in the face of a serious error — up-time was the most important metric. The experience of working in commercial telecom taught me to appreciate alternative approaches to fault tolerance. Her, too, we used custom hardware and firmware, but the culture was much looser in terms of process when compared to mission critical defense systems. Here, we used assembly, C, and C++, while in the defense world, we used assembly and later Ada, and then C. For a long time, C compilers were not trusted; the fear was that trap doors and other vulnerabilities could be inserted by the compiler unbeknownst to the programmer.
Next, I joined the research world — a world I didn’t know existed. It felt like working on a college campus. Here, teams are relieved of the pressure to deliver a fully complete product, hence process overhead was very light. Research teams research innovative ideas by building functional prototypes but they often skip implementation of corner cases. Once completed, the proof-of-concept is zhuzhed up into a product by a business unit — and this is where every corner case is addressed to build a viable and robust business or product. The goals in this type of job are to build prototypes, publish research papers, and file patents. The idea is to free the researchers to explore advanced ideas that are five to ten years ahead of the current state of technology.
Finally, I’ve had the opportunity to join academia which matches closely to the research environment I worked in, but with the additional chance to provide instruction and mentoring to a new generation of graduate and undergraduate software engineers and data scientists.
STEM students who are looking for freedom to implement a great new idea they have could consider working in a research environment or academia. They might also enjoy the challenge of establishing their own startup. These are the environments where there is flexibility and freedom to pursue your own ideas. These projects are typically high risk — there are no guarantees of success and often you are faced with significant obstacles which have never before been encountered, or solved.
Non-research projects are less risky by design — stable, existing technologies are chosen, especially in defense systems. There is a lot of process overhead to ensure the entire team works in a predictable way to write, test, deploy, and maintain code. There is high likelihood of the project’s success, there is extensive planning by project managers, and schedules are closely watched for progress.
2. Although you participate in several non-academic activities, many of those roles — mentoring at NYAS, or advising start-ups— still contain a teaching component. How did you start mentoring others, and why did you decide to continue?
As a mentor, I hope to be the link between future engineers and the fine professors and engineering colleagues who generously shared their knowledge with me. My goal is to pay it forward : )
3. What has been the proudest moment in your career thus far?
The proudest moment in my career was earning the chance to design and develop a secure embedded realtime operating system for secure radios deployed in the tactical internet. This InfoSec work led to a thesis on secure operating system design, and a first paper published in IEEE MilCom 2000.
