TITLE: Practice What I Preach AUTHOR: Eugene Wallingford DATE: November 12, 2006 11:34 AM DESC: ----- BODY: One of my colleagues occasionally comments that many of the folks in our department don't often practice in the rest of our professional lives what we preach in our areas of technical expertise. For example, in software engineering we often speak of the importance of gathering requirements, writing a complete specification, and then later testing our product to ensure that it meets the spec. But CS faculty are often reluctant to practice these ideas in the context of curriculum and departmental mission, which leads to a lack of motivation for tasks such as academic program review both on the side of specifying concrete department goals and concrete course competencies and on the side of measuring outcomes. My colleague's observation is usually true. Expertise doesn't transfer very well across domains of practice; and, even when the mindset transfers, the practices and habits don't. It takes a lot of work to translate the mindset into the new habits we need in the new domain, and we have to watch out for pitfalls that let us convince ourselves that the new domain is so different that we can't practice what we preach. Though my colleague has never made his observation to me when commenting on my performance, I know well that I am guilty. I strongly encourage the use of agile methods in software development, and I've even written in this space on how I have intended to "be agile" in how I approach my administrative duties. But as I look back over my first fifteen months as a department head, I see a path littered with good intentions leading to a very different place than I wanted to be. Cast of 'One Day at a Time' I had hoped to write a retrospective of my first year in the Big Office by now, but I haven't yet -- in part because I don't feel I have synthesized much of an understanding of what I do yet, but also in part, I think, because I feel a bit ashamed of my weaknesses. I haven fallen woefully behind on several major projects, including ones that were centerpieces of my desire to become head. As I look back, I see many of the signature problems of big software projects falling behind. As Fred Brooks tells us in The Mythical Man-Month, how do disastrously late projects get that way? "One day at a time." When I fall farther behind, it is rarely because a major task preempts my time; most of the slippage in my schedule results from "termites" -- little interruptions, small distractions, and bad decisions made in the small. I am agile in mindset, but not in practice. How can I change that? Go back to the basics: Define small tasks. Define "tests" that will help me know that I have made concrete progress. Release small deliverables frequently to the folks who depend on my work, especially the faculty. I know what to do. Now it is time to get serious about new practices for the new tasks I tackle. -----