FAQ: Resume
Douglas B. Moran

Introduction: This document provides some additional details about my skills and experiences and addresses some of the Frequently Asked Questions about the connections between portions of my background.

Table of Contents


Management Skills

Leadership: Most of the people I have managed have been very bright and highly motivated, so my role as a leader has been to provide focus, to remove obstacles, and to promote teamwork. I am at core a teacher/mentor. Multiple team members have told me that I am one of the best teachers that they have ever had and that they learned more on my projects than on any others they had worked on. In addition to the usual goals of professional satisfaction and advancement of staff, such educational efforts often pay significant dividends on current efforts because they prompt staff to take a wider view of their tasks, enabling them to spot opportunities and approaches that are often missed when one is too focused on the task at hand.

Process: Part of my success as a project leader and as a computer facility manager was implement effective processes: ones that were a match to both the problem and the people that had to execute them. Operating in environments where many people tended to be dismissive of administrative procedures, I was effective in persuading them of the benefits of following mine (as well as various other ones).

Planning: On projects at SRI, budgets, schedules and staff levels were subject to significant change with little or no notice. Hence, my experience in planning projects emphasized scheduling project tasks to minimize the effects of this unpredictability. At Recourse, there was a more traditional planning environment, and I found it very useful to be paired with someone who had more experience in the traditional approaches.

Recruiting: At both SRI and Recourse, I had substantial involvement in the recruiting process. As a computer facility manager (at SRI), I created an interview form and process for system administrators that were adopted by other departments.

Personnel Management: Although I was never a line manager at SRI, as a project leader and computer facility manager I had a substantial role in personnel evaluation and decisions.


Communication Skills/Marketing

I am highly regarded for my technical presentations in a variety of media: In addition to presentations about my own projects, colleagues have actively sought my inputs on improving their presentations.

At Recourse, I wrote the initial whitepapers for both released products, and these were heavily reused in a series of subsequent publications. I was also responsible for the company's positioning statement ("threat management": merging "threat assessment" and "risk management").


Software Engineering Approach

Methodology: I am most comfortable with software engineering practices that are currently called agile methodologies, and I anticipate that these methodologies would be the best fit for the types of projects I would likely be undertaking.
In my second summer as a programmer, I discovered that the process of extracting a task specification from a (internal) customer radically changed his notion of what could and should be done, and that this recognition takes time, often manifesting itself well after the customer has agreed to the spec.
I have repeated seen how even a minimal operational prototype changes the notion of what the system should be for both the customer and the developers.
My preferred approach is to use rapid prototyping to allow early integration of components, and to emphasize an early start to testing against realistic data. I expect this testing to yield a variety of surprises (some good, many not). This prototype-and-test cycle provides an incremental refinement of the specification. This approach works well for me because my experience allows me to structure the development process so that the big "surprises" are likely to be encountered early, and hence have less of an impact on the schedule.

Documentation: I believe in the creation of operational prototype early in the development cycle, and iteratively enhancing the functionality. I believe in early documentation of components: My experience is that the documentation process helps the developer discover weaknesses in the design. And if a component's developer has problems describing it, that strongly indicates the presence of conceptual confusions that will manifest themselves as bugs in the implementation of that component and errors in the usage of that component by other components.

Testing: My experience with AI systems has impressed on me the value of early testing with realistic data sets. This testing is more than just finding bugs and performance problems: It is an opportunity to better understand your design and implementation. It is not unusual to find that you have failed to exploit a feature of the data sets that allows significant simplification or speed-up of the code. Early testing facilitates incorporating these insights into the design and implementation.

My projects have involved early creation of unit tests and regression testing. In a commercial environment, I like to have QA involved from the earliest stages of the project, setting up a testing framework that the developers can use, and which then allows the development test process to provide a kickstart for the full QA process (and, yes, I do know that many QA people are not used to operating like this).


Relevance of Software Development Experience in Sponsored Research to Commercial Environments

People tend to be very surprised when I tell them that there was surprisingly little difference between my sponsored research activities at SRI and my work at a startup (Recourse). At SRI, I needed to bring in $2-3M per year to support my projects. To do this, a significant portion of my time when into marketing: market assessment, competitive intelligence, "elevator pitches" to likely funders, and more detailed technical presentations to the broader community.

I actually found that sponsored research had more demanding software engineering practices than the startup. My research projects required early and frequent demonstrations, and these demos were a valuable companion to the agile software engineering methods being used: They kept the developers focused on the system's key attributes, on its usability, and its existence as a system (rather than a collection of components). The need for "bullet-proof" demos that could be given by people outside the project (managers, the client) provides an emphasis on testing and other QA concerns from the earliest stages of development.

Non-trivial build management has also been a part of my research programs. The typical research program has multiple clients (either as a consortium or in related projects) and is being marketed to a range of potential new clients. Each client and marketing activity would have its own customized version of the basic system, with capabilities developed on these branches being incorporated into the basic system as they became stable.

Sponsored research also teaches you to evaluate and pursue potential strategic partners: Clients typically seek to leverage their funding of research by pushing various relationships. Risk assessment and mitigation for these relationships essentially the same as I saw in the commercial environment.


Relevance of Artificial Intelligence to Intrusion Detection

Work in Intrusion Detection has many similarities to work in Artificial Intelligence. Both have to deal with legacy systems that, as they have evolved to meet changing circumstances, have accumulated masses of special cases and patches. Consequently, the range of possible inputs is often very large and poorly understood, and replete with idiosyncrasies.

Since the system designer does not control the inputs to the system, the system must be able to handle ambiguous and incomplete data. Furthermore, the inputs can contain data of questionable reliability.

Developing successful approaches often involves substantial experimentation: collecting data and analyzing it, and then looking for additional data sources that can be used to reduce the error rate (false positive and false negatives). Because of complex interactions between data items, often one needs to implement substantial systems that run on substantial data sets in order to find the inadequacies of the current approach.

Search is also a key aspect of both Intrusion Detection and Artificial Intelligence. Intrusion Detection involves finding the miniscule number of events that are suspicious, correlating them with other events, and organizing the resulting collection into a meaningful pattern. This is essential the same process for generating a plan, processing an image, or understanding a sentence. Intrusion Detection, there are a miniscule involves the detection


Version: $Date: 2001/12/01 01:23:37 $