Table of Contents

• Management Skills
• Communication Skills/Marketing
• Software Engineering Approach
• Relevance of Software Development Experience in Sponsored Research to Commercial Environments
• Relevance of Artificial Intelligence to Intrusion Detection

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.

• Papers of a range of lengths.
• Presentations to a variety of audience types and sizes.
• Software demonstrations with a range of optional components, thereby allowing them to be tuned to different audiences, including retargeting during the demo.
• Video version of key demos.

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").

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.

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).

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.

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