The Artima Developer Community
Sponsored Link

Building Adaptable Systems
A Conversation with Andy Hunt and Dave Thomas, Part V
by Bill Venners
March 31, 2003

<<  Page 4 of 4


Building Frameworks

Bill Venners: In your book, you say "You may even be able to implement several different projects using the same app engine, but with different metadata." That makes alarm bells go off in my brain. I get nervous when people say, "Let's go build a framework for our app, instead of building the app."

Dave Thomas: Absolutely, I couldn't agree more. You want to avoid focusing on the framework. The framework supports the application you're writing. You start writing the pieces and realize you need a way to glue them together. You write whatever you need to glue them, but you don't take it any further than that. The mistake people make is saying, "OK, I'm going to write these components. That means I need a framework," and starting with the framework. I can guarantee that any project that starts by writing a framework will never finish writing the framework.

Andy Hunt: When you are working on framework code, if you find yourself saying, "OK, I'm going to add this feature to the framework just in case we might need it," don't. A framework is not the place you want to do something you might need. You want to be much stricter and say, "I need this framework feature now to support my application, therefore I'm going to add it to the framework."

Dave Thomas: Andy and I wrote a debit card switch as our first project together. We wrote it as a very decoupled hungry consumer model. We needed a way of having multiple processes talking back and forth with each other. We initially figured we'd have to write some kind of high falutin framework to do that, but we just ended up using Unix sockets. The whole communication mechanism implementing two way priority queue messages with flow control was probably about 150 lines of code. That very simple and trivial code was all the framework we needed. Had we started off saying, "We're designing this high performance distributed application with lots of processes. We need a framework to support it," that would have been an entire project in its own right.

Andy Hunt: We'd still be writing it.

Dave Thomas : We would still be writing it.

Without the code that uses a framework, you'll never know when to finish the framework, because you'll never know when you've done enough. You'll always be guessing. So start the other way around. Always write the code first, then plumb in the least amount of glue you need to make it all work.

Andy Hunt: Whenever you have to make a decision like that, you want to know, not guess. Dave was just saying, "How would you know when you're done building the framework?" By taking the approach Dave just suggested, you have a way to know exactly what you need. If you did it the other way around, you wouldn't know what you need. You would have to guess. So don't guess, know.

Next Week

Come back Monday, April 7 for Part VI of this conversation with Pragmatic Programmers Andy Hunt and Dave Thomas. If you'd like to receive a brief weekly email announcing new articles at, please subscribe to the Artima Newsletter.

Talk Back!

What's your opinion of adaptability? What should be made adaptable? What shouldn't? Discuss this article in the News & Ideas Forum topic, Building Adaptable Systems.


Andy Hunt and Dave Thomas are authors of The Pragmatic Programmer, which is available on at:

The Pragmatic Programmer's home page is here:

Dave Thomas was not the first person I've interviewed who mentioned the arcade game Whack-a-Mole. James Gosling also called upon the versatile Whack-a-Mole metaphor while pointing out that it is sometimes hard in engineering to know if you've solved a problem or moved it:

The Agile Manifesto is here:

Ward's Wiki, the first WikiWikiWeb, created by Ward Cunningham, is here:

Extreme Programming: A Gentle Introduction: An Extreme Programming Resource:

<<  Page 4 of 4

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use