Monday, November 27, 2006

How I Do Design

This past week I spent some time working with some guys doing design work.  As we ping-ponged ideas and styles back and forth, I had opportunity to express my quick list of questions I ask when doing design. It turns out someone took notes so I've provided them here.  Maybe you will find them interesting...

Do I have enough information to design what I am trying to design?
  1. What kinds of data?
    • Hard types or not? Using classes vs. datasets or xml vs. text
    • Comprehensive or not? Is the data normalized, are the options well-known and relatively static.
    • Calculated or not? Does it require staging, heavy calculations, is volatile?
    • What's the lifecycle? Where does it come from, where does it go? What determines the states it has?
  2. What kind of process are you designing?
    • Displaying information? How rich is the interface?
    • Collecting information? What speed is the collection? How controlled is the interaction?
    • Business Rule Processing? Where does context come from? What is the rate of change (ROC) for the rules?
    • Transforming Data? Are the schemas well-defined? What is the ROC for the logic? 
    • A Workflow? Does it interact with user? How complex is the state machine?
    • Others – specialties? Hybrids?
  3. What patterns already implement similar behavior?
    • Ex: ui - > validator - > access server -> data contract
    • Framework provides the patterns.
    • Consume others as appropriate.
    • If you can’t define it using patterns, define it using prose.
    • Patterns are succinct, you only have to call out the exceptions.
  4. What is unique about the behavior being implemented?
    • Start with prose – write it out, follow the Design Considerations template.
    • Move to formalizing your design – use patterns/practices to describe processes.
    • Break it out and keep the scope of each component small and isolated.
  5. What are the operational considerations?
    • Security? How much or little trust? How controlled, and managed?
    • Retention? Lifecycle of data and the artifacts from processing.
    • Performance?
    • These data points go into the Requirements Map.
  6. What specific services are to be consumed?
    • Using particular APIs? Controls? Schemas?
    • Whatever specifics you know (typically filled in detailed design)
    • If you know it, put it in the Design Considerations document
 These were just my off-the-top list, so keep the flames low, eh?

Post a Comment