The Artima Developer Community
Sponsored Link

Becoming an Architect
A Conversation with Luke Hohmann, Part IV
by Bill Venners
April 5, 2004

<<  Page 2 of 3  >>

Advertisement

Sticking with a Product Release after Release

Bill Venners: In your book Beyond Software Architecture, you write, "You're not an architect after your very first job. You're not an architect after the first release. There is simply no substitute for sticking with a problem long enough to receive and process the feedback generated through customer use of your system." What kinds of lessons can be learned through actually seeing the results of your decisions at a much later time that you wouldn't learn otherwise?

Luke Hohmann: Let's compare two candidates whom we are considering hiring for one open position. The first person says, "Hi Luke, here's my resume. I was the architect for this system. I did it, and then I moved on. Then I did this system, and I moved on. I did this other system, and I moved on." That person has the advantage of seeing different problems. I'll give them that. It's not one year of experience five times, it's five different kinds of experiences. But let's compare that to the other person, who says. "Hey look, I did this system through three releases, and I did this system through two releases, and then I did this system through four releases." I can have a qualitatively different conversation with that second person. I can ask, "What did you learn about the first system that informed your choices for the second?" What did the first person learn about the consequences of their decision that helped them make a better choice for the next system? Nothing, because they weren't around.

Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked. Is it better to give each table a column named <table name>id or id? Which is better? A person who sticks with a product as the database schema migrates and changes over time will be able to give you an answer.

<<  Page 2 of 3  >>


Sponsored Links



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