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