Last fall, I gave a keynote at OOPSLA titled What Drives Design? You can view my presentation, thanks to a podcast recorded by InfoQ. I was slightly chagrined to read the one comment on the site:

Funny, I thought that requirements are the main driving for for the design. [The] author made me feel like I was blind all these years...Kidding aside, all these forces [the] author mentions are secondary forces, while requirements should be the primary and the commanding force.

My first reaction is, well duh! I was trying to get behind that to an explanation of our design roots and current practices. Requirements may constrain what are valid solutions, but the choices you make as you design and implement a solution are wrapped up in your design values, aesthetics, practices, and development rhythms. As the person who coined the meme, “xxx-driven” that is used to characterize various driven practices (think Respsibility-Driven Design or RDD, TDD, BDD, AMDD, FDD, etc.) I presented a brief history lesson about how certain software design practices came into being, what values are associated with them, and how these values might conflict or co-exist.

I also challenged the software community to stop being so blindly “driven” and take a closer look at why they follow certain practices. Of course requirements should drive design. But what then drives the way you approach your work? I believe that from time to time it’s good to pause to reflect on what you value (and what you think makes a design solution good) before integrating new techniques and practices to improve your work.

If you watch my talk, I’d love to hear about what you value and thoughts on how you approach design.