TITLE: A Non-Software Example of Preparatory Refactoring
AUTHOR: Eugene Wallingford
DATE: April 04, 2019 4:40 PM
DESC:
-----
BODY:
When I refactor my code, I most often think in terms of what
Martin Fowler calls
preparatory refactoring:
if it's difficult to add a new feature to my program, I refactor
the existing code into a state where the feature fits naturally
somewhere, then I add the feature. As is often the case, Kent
Beck captured this notion memorably in
a tweet-sized aphorism.
I was delighted to see that Martin's blog post, which I remember
fondly, cites the same tweet!
Ideas from programming are usually instances of more general
ideas from the broader world, specialized to a world of bits
and computation. Back when I taught our object-oriented
programming course every semester, I often referred my
students to a web site that offered real-life examples of the
various design patterns we were learning. I remember an
example of Decorator that showed how we can embellish a
painting with a matte or a frame, and its use of the U.S.
Constitution's specification of the President to illustrate
the idea of a Singleton. I can't find that site on the web
just now, but there's almost surely a local copy buried in
one of my course websites from way back.
The idea of refactoring is useful outside the world of software,
too. Just yesterday, my dean suggested what I consider to be
a preparatory refactoring.
A committee on campus is charged with proposing ways that the
university can restructure its colleges and departments. With
the exception of a merger of two colleges a few years ago, we
have had essentially the same academic structure for my entire
time here. In those years, disciplines have changed and
budgets have changed, so now the administration is thinking
that the university might be more efficient or more productive
with a different structure. Thinking about the process from
this perspective, restructuring is largely a reaction to change
that has already happened.
My dean suggested another way to approach the task. Think, he
said, of the new academic programs that you'd like to create in
the future. We may not have money available right now to create
a new major or to organize a new research center, but one day
we might. What university structure would make adding this
program go more smoothly and work better once in place? Which
departments would the new program want to work with? Which
administrative structures already in place would minimize
unnecessary overhead of the new program?
As much as possible, he suggested, let's try to create a new
academic structure that suits the future programs we'd like to
build. That will reduce friction later, which is good:
Administrative friction often grinds new academic ideas to a
halt before they get off the ground.
In programming terms, this is quite bit different than the sort
of refactoring I prefer. I try to practice
YAGNI
and refactor only for the specific feature that I want to add
right now, not taking into account imagined future features I
may never need. In terms of academic structure, though, this
sort of ip-front design makes a lot of sense. Academic
structures are much harder to change than software; getting a
few things right now may make future changes at the program
level much easier to implement later.
Thinking about academic restructuring this way has another
positive side effect: it might entice faculty to be more
engaged, because what we do now matters to the future we would
like to build. It's not merely a reaction to past changes.
My dean is suggesting that we build academic structures now
that make the changes we want to implement later (when the
resources and requisite will exist) easier to implement.
Building those structures now may take more work than simply
responding to past changes, but it will be worth the effort
when we are ready to create new programs. I think Kent and
Martin might be proud.
-----