Wednesday, November 29, 2006

Serious Confusion

In my reading, I came across an excellent post about the estimation process for software development.  The author (Serious Confusion) does a solid job of summing up his views with style.  I encourage you to check it out here.

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?

Monday, November 20, 2006

Tic and Tie

Many years ago I worked routinely with finance people.  Lately, I find myself in their midst yet again.  On my latest engagement, I've been coming across an interesting phrase for which I haven't been able to find a solid etymology.

The phrase as Tick and Tie. Or maybe Tic and Tie? Or ??

There are many people that use this phrase, managers, accountant types, legal eagles, etc.  They all seem to provide their own subtext and implications, but somehow they all seem to understand what it means by unspoken agreement.  When pressed, no solid answers were at hand.

As best I can figure, it relates to checking the numbers or answers, and relating the specific numbers or answers to their supporting information.  When working a proposal, projection, or model, this is a crucial step necessary for validating that all the information can be defended.  During facilitation we call this  the clarify step.  In computer terms we call it a check-sum.

Lacking a good definition, I'm presenting a bogus history.  Tick as in making check marks (ticks) on each entry. And Tie as in connecting each item back to the supporting documentation from which the number is derived.

If you've got the real one, I'd love to hear it.