What Drives Design?
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:
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.
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.
posted by Rebecca Wirfs-Brock at
8:25 PM
5 Comments:
I like the words from one of your slides: design between the keystrokes. I'd like to print out and put them near to my screen, so that they being always hold in mind.
I really "feel" the values of TDD. Especially the aggressive approach of writing tests - you write your test as it easy to be written and just that points you to the right direction for design decisions about you code.
If someone ask me about which interface should be there or how I spread responsibilities between classes, I always say that only test (first) can show.
I totally agree that requirements is not what drives you design. It's not a tool for making decisions. All programmers always have requirements when they're writing code, but not all of them do it great.
Alsor-
I like that characterization, too. But one fervent TDDer I know very well who attended OOPSLA thought I was putting down TDD by that phrase. I had no such intent. It really is a matter of if you were to looking for where people were "designing" when they practice TDD, it would be in the conversations they had with their colleague before they wrote the next test.
I think that there are different rhythms for design and that sketching out a general idea or using CRC cards to model a bit before starting to code also fits into an agile frame of mind. Especially when something is new and uncharted.
Cheers,
Rebecca
Rebecca,
I enjoyed your article because I see TDD as a form of writing "executable specifications", and I can confirm that design takes place in conversations before writing the next test ... ahem ... executable specification.
Cheers, Matthias
Requirements keep changing.Good design ensures changes get accommodated well. I have never seen "Good requirements". They are always incomplete. (And that's why we exist, Software Engineers :))
Domain model as a glossary, sequence diagrams as roadmaps and TDD as "completely verifyable specification" are the driving forces in my projects. CRC cards help a lot when clustering domain model elements and creating sequence diagrams. Thanks for the articles and the book "object design".
Post a Comment
Subscribe to Post Comments [Atom]
<< Home