The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Abstraction and Detail
A Conversation with Andy Hunt and Dave Thomas, Part IV
by Bill Venners
March 24, 2003

Page 1 of 3  >>

Advertisement

Summary
Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about an approach to design in which details are pulled out of the code and stored as metadata.

Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software. Their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), is filled with practical advice on a wide range of software development issues. They also authored Programming Ruby: A Pragmatic Programmer's Guide (Addison-Wesley, 2000), and helped to write the now famous Agile Manifesto.

In this interview, which is being published in ten weekly installments, Andy Hunt and Dave Thomas discuss many aspects of software development:

Put Abstractions in Code, Details in Metadata

Bill Venners: In your book, The Pragmatic Programmer, you say, "Put abstractions in code, details in metadata." What do you mean by that?

Andy Hunt: Abstractions live longer than details. Details are volatile. Because details are going to change, put the details where changing them will create the least amount of friction. Typically that's outside the code base—in a database, a properties file, or XML—something acting as metadata. We suggest an overall architecture where you put your energy into creating the right abstractions in the code. And as much as possible, push the details out somewhere else where they are easier to change, because that is what's going to change.

Our philosophy contrasts with eXtreme Programming's (XP) attitude of trying to not look very far ahead, to just do the absolute minimum required at any point in time. We think where you put the details is a matter of investment. You're taking some risk when you make details easy to change that it will wind up not being necessary. But for me personally, almost every time I've taken that extra care to make a system flexible, it has saved me. So we advocate this approach very strongly in the book.

You get a feel for knowing what's going to change. The user comes in and says, "It's going to be blue. No, no, green. Nope, it's going to be blue." If they've already changed their minds four times, odds are they're not done yet. You know that's going to be volatile. Anything dealing with legal requirements is more than likely going to be volatile, so move that out where it will be easy to change.

Dave Thomas: When people read our advice in the book about metadata , they tend to imagine very complicated architectures with lots of abstraction. But in reality, it could be very simple. If the sales tax rate is currently 7%, I don't put 7% into the code. I put it into a properties file or the database. The sales tax rate is a detail I abstract out of the code and store externally.

Once you're comfortable with pulling out simple metadata, like a sales tax rate, you can go further. You can start asking yourself, "What are the actual chunks of code that I'm processing to handle this particular order of business?" For example, I implemented an online order entry system in which the processing was spread out over a number of months, depending on how payments were received. I implemented it as a set of individual business functions controlled by a state machine. I defined all the states and state transitions in a database. My abstractions were individual chunks of functionality. Metadata in the database controlled how they worked together.

That architecture saved me, because the customer kept coming back saying, "When a purchase order arrives, we actually need to do this but not that." Rather than change six pieces of code to make the system act differently, I only had to update the state machine in the database, and everything just worked. Pulling details out into metadata doesn't need to be complicated. It doesn't necessarily represent more work. It just requires a different kind of work.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us