The Models ARE the Code
May 3, 2006 § Leave a comment
Nothing's absolutely more disheartening than hearing the customer pipe out upon seeing the latest testing version of the shiny new hi-fi platform solution you've uncovered, "But this isn't what we asked for!"
You blink, fight for air, and your eyes roll over. What in tarnation is the customer rambling about? Didn't your software team pore thru every millimeter of the System Design Specification, verify it against the System Requirements Specification and throw every conceivable verification gimmick at it?
Sure, you concede, a few changes and customer requirements were known only later in the play, and so were directly sourced off to the codebase. But that's not much, is it?
"No no no!" the customer's now positively ballistic, and if you didn't care so much about being a genteel person, what words you wouldn't use!
Turns out, you're both right, and you're both wrong. The solution only captured the customer's stated needs and not the actual needs. There was no validation, only verification of constructed artifacts. The codebase you've implemented is hopelessly anachronic with the original design specs.
Why did this (all too frequent) scenario come about?
Buzz. Here's the answer:
- Were you cutting yourself just a bit too much slack in sourcing change requests directly to the codebase?
- Did you or the customer view the SRS as an immutable project flag-off artifact?
- Did you not collaborate enough with the customer to elicit and understand the actual needs and not the stated wants?
- Was there no feedback into your platform model when changes were patched directly onto the codebase?
Not the silver bullet definitely, but if we begin to view our platform models not as archaelogical artifacts dating to pre-sign-off periods of a project but as valuable information and decision making tools and source all changes thru the platform specs and not via band-aid programming, that would definitely be the day.
Sadly, we are still left crooning "When…" like Shania Twain….