Posts
Software Development lessons from our Founding Fathers
Who knew that Washington and Jefferson had experience with Software Development? When they were discussing the methods (methodology?) by which the people should be governed, they split the power that government can wield into three branches. In doing so, the founding fathers tapped into a very fundamental division of responsibility. By forcing each division, or branch, to work *with* the other branches sometimes and *against* at other times, they intended to balance the power of any one branch and work to check the abuse of power by all branches.
*From the back row* "What does that have to do with software? The man's gone daft!"
Hey, I'd give your money back but this is a free lecture.
Ok, maybe the civics lesson is boring so I'll summarize:
Legislative - Decides on and Defines law
Executive - Implements and enforces the law
Judicial - Interprets the law and decides whether the implementation follows the law as defined
It didn't take much of a stretch to come up with the following roles and responsibilities:
Customer - Decides on and Defines features
Developer - Implements requested feature
Tester - Interprets the feature, Decides whether the implementation follows the definition.
For those who just woke up, here are the Clif-Notes:
Legislative (Customer)
Executive (Developer)
Judicial (Tester)
Again from the back row: "If software development has three branches does that mean that it also has 'Checks and Balances'?"
I'm glad you asked that question! Of course it does, give that man a cigar! Let's use the tool we get all our information from, the idiot box.
*static*
[CLICK]
It's lah---og, it's lah---og,
It's brown! It's round! it's wood!
*This is a story. *
*About a man named Brady.*
Checks and Balances
Feature Definition:
- Customer requests a feature
Scenario 1 (signs law)
- Developer accepts feature
Scenario 2 (veto)
- Developer vetoes a feature request(feasibility, priority, poor definition, not testable, etc.)
- Customer does not overrides the veto (low priority, nice-to-have)
Scenario 3 (override veto)
- Developer vetoes a feature request(feasibility, priority, etc.)
- Customer overrides the veto(raising the priority, accepting constraints, etc.)
Feature Development:
Scenario 1 (default)
- Developer implements feature
- Developer submits feature for testing
- Tester validates feature
Scenario 2 (improper implementation)
- Developer fails to implement and/or submit feature for testing
- Tester declares feature fails test by default
- Tester notifies Customer of incomplete feature
Scenario 3 (renegade implementation)
- Developer implements unwanted feature
- Tester decides not to include it in the application
- Customer cuts funding (power of the purse)
Feature Testing:
- Customer provides a testable feature request
- Developer agrees to the test definition
- Developer implements feature
Scenario 1 (feature passes test/upheld)
- Tester declares feature as working as requested
Scenario 2 (feature fails test/struck down)
- Tester declares feature as not working as requested
- Feature returned to developer for further work
Scenario 3 (feature passes test but Customer disagrees)
- Tester declares feature as working as requested
- Customer disagrees and thinks the feature is not complete
- Customer submits a refined new request with an updated feature definition (new legislation)
Without the Testing branch, there can be no checks and balances between what was requested and what was delivered. It is a peer to the other two and should not be seen as subservient.
For all those non-coders, pretend you are back in Speech 101 class. They teach you to tell them what you are about to say (state the requirement), say it (code the feature), then tell them what you just said (test the feature)?
