Challenges and Stories
Q7: In your current role, what are the biggest challenges, and their solutions? How does this relate to business?
A:
Challenge one: Computers start at the bottom with things like transistors and logic gates, and build up all the way to social processes and psychology and legal issues. It's important to be able to move between these abstraction levels; if you're working primarily on one, it's important to be able to project its implications above and below. However, in my life as a professor (my third career now), it's getting more common to see students who have trouble with this projection, with things like relating their high-level program to machine behavior. Their challenge becomes my challenge!
Solution: I'm still working on this!
Challenge two: Building a software product typically involves getting the most features to the most customers in the shortest amount of time possible. The way we build software is built around this paradigm. However, this approach is in direct opposition to building secure software. If security were the most important thing on the list, we'd axe features that were risky, spend more time in design and code reviews, and do much more negative testing. My job often involves trying to balance these two approaches.
Solution: Well, there isn't any hard and fast rule here; each project is different. Ultimately, it often boils down to a risk management decision.
Q8: Please share some stories (something surprising, unexpected, amazing, or humorous) from your work?
A: Boundaries are where the trouble is. In my industry work, whenever we drew a boundary between the "hardware functionality" and the "software functionality" it was wrong - we ended up wrestling with subtle interactions that did not pay attention to our naïve distinction.
As a student, when your code doesn't work, it's easy to blame the system and the tools instead of yourself. However, in the real world, I was surprised to see that, now and then, it really was the system. The tools themselves didn't work!
In my consulting days, I would often approach a project with a clear idea of where the security issues were - only to discover that, once I started talking to the clients and learning the broader context, my initial view was wrong (or at least overly simplistic). In these engagements, I learned a lot (on a meta level) from a retired Treasury agent who was on our team - and who was probably the smartest "people" person I've ever known. That helped make it easier to see the client's context. School doesn't spend enough time on that sort of thing.