Sponsored Link •
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
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.