Sponsored Link •
Luke Hohmann talks with Bill Venners about entropy reduction, the cost of change, and programming as choreography.
Luke Hohmann is a management consultant who helps his clients bridge the gap that often exists between business and technology. In his past experience, he has played many of the varied roles required by successful software product development organizations, including development, marketing, professional services, sales, customer care, and business development. Hohmann currently focuses his efforts on enterprise class software systems. He is the author of Journey of the Software Professional: A Sociology of Software Development (Prentice-Hall, 1997), which blends cognitive pyschology and organizational behavior into a model for managing the human side of software development. He is also the author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003), which discusses software architecture in a business context.
On March 8, 2004, Bill Venners met with Luke Hohmann in Sunnyvale, California. In this interview, which will be published in multiple installments on Artima.com, Hohmann discusses software architecture in the context of business.
Bill Venners: In your book, Beyond Software Architecture, you write:
Architecture degradation begins simply enough. When market pressures for key features are high and the needed capabilities to implement them are missing, an otherwise sensible engineering manager may be tempted to coerce the development team into implementing the requested features without the requisite architectural capabilities.
You then advise scheduling some time after each release for "entropy reduction" to pay off technical debt accumulated during the push to get the release out the door. What is entropy reduction?
Luke Hohmann: In most of the enterprise systems I've built, I could show you where it is a model of really well done design. It has three tiers like the books recommend. It responds and adapts well to the needs of the market. It works really well. But in that same system, I could show you part of it that is a complete and utter, ugly hack. It was 2AM and we had to ship in three days, and we just hacked that part together.
I think refactoring coupled with the right things, automation and test-driven design, is wonderful. They all work together to help make software more changeable—and more safely changeable—than it was in the past. But when it's time to ship and you've got to hit code freeze, that refactoring stuff is the least important thing in my mind.
You brought up the concept I call entropy reduction, which is quite possibly an idiosyncratic way that I like to run projects. After a release, I spend some time trying to hold the features of the system constant and just clean up the inside a little bit. Before I start on the next release, I take the known technical debt, the known entropy that was introduced, and clean it up. It's like putting a hold on refactoring to get the release out the door, and then turning on refactoring again afterwards. Because you have to turn refactoring off if you're going to ship.
Dave Quick from Microsoft once told me that the way he refers to this idea is that if you actually want to ship, shipping becomes a feature. You've got a list of features you want to hit. If you're going to ship, shipping becomes a feature as well, either explicitly or implicitly. You need to do what is necessary to get that feature done too.
Entropy reduction means I am going to make whatever compromise I need to make to get the release done, and then I'm going to give the team the opportunity to go back and respond or recover from the compromises they made. It is a very different concept than refactoring. I think of refactoring as non-architectural, but rather very much in the context of normal work.