Archive
Shall And Shall Not
For a controlled system to remain viable and stable, Ashby’s law of requisite variety requires that the system controller(s) exhibit a wider variety of behavior than the system controllee(s). This can be accomplished by either the controller increasing its variety of responses to controllee disturbances, or by decreasing the variety of controllee disturbances relative to its own variety of control responses, or both.
In order to comply with Ashby’s law (in conjunction with several other natural laws – 2nd law of thermo, control theory, Turing’s infallible/intelligence thesis, etc), Bill Livingston asserts that membership in any institution requires the internalization, either consciously or (more likely) unconsciously, of the following set of “shall” and “shall not” rules:
As you can see, suppressing variety in the controllee population is the preferred method of a controller aiming to satisfy Ashby’s law. The alternative, increasing its own variety of response relative to controllee variety of disturbance, requires learning and development. By definition, infallible controllers don’t need to learn and develop. They stopped learning when they achieved the status of “infallible” – either by force or by illusion.
So, what do you think? Did Mr. Livingston hit the bullseye? Miss by a mile?
Out Of One, Many
A Software Product Line (SPL) can be defined as “a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way“.
The keys to developing and exploiting the value of an SPL are
- specifying the interfaces and protocols between app components and infrastructure components
- the granularity of the software components: 10-20K lines of code,
- the product instantiation and test process,
- the disciplined management of changes to the app and infrastructure components.
- managing obsolescence of open source components/libs used in the architecture
- keeping the requirements and design data in synch with the code base
Any others?
Your Operational Configuration
Which system configuration do you prefer? Which system configuration is most prevalent in nature? In the “civilized” world? What’s your operating configuration, and do you have just one?
Idealized Design
Russell Ackoff describes the process of “Idealized Design” as follows:
In this process those who formulate the vision begin by assuming that the system being redesigned was completely destroyed last night, but its environment remains exactly as it was. Then they try to design that system with which they would replace the existing system right now if they were free to replace it with any system they wanted.
The basis for this process lies in the answer to two questions. First, if one does not know what one would do if one could do whatever one wanted without constraint, how can one possibly know what to do when there are constraints? Second, if one does not know what one wants right now how can one possibly know what they will want in the future?
An idealized redesign is subject to two constraints and one design principle: technological feasibility and operational viability, and it is required to be able to learn and adapt rapidly and effectively.
So, are you ready to blow up your system? Nah, tis better to keep the unfathomable, inefficient, ineffective beast (under continuous assault from the second law of thermo) alive and unwell. It’s easier and less risky and requires no work. And hey, we can still have fun complaining about it.
Quid Pro Quo
Forget about the superficial, ceremonial, “empoyee survey” that is often ignored and quickly forgotten. Wouldn’t it be a great quid-pro-quo move to “allow” each employee in an org to formally judge his/her organization’s behavior, I mean performance, once a year? The content of the review form could be similar to the one in which the employee him/herself is evaluated. After filling out a set of multiple choice questions and allowing for free-form input to justify the selections, an overall behavioral rating could close the review. The rating could be selected from an enumerated list similar to this:
- Exceeds Expectations
- Meets Expectations
- Needs Improvement
- Unacceptable
Based on the final rating, instead of giving the org a merit increase, the employee would communicate the level of commitment that he/she will really provide in the coming year:
- Total Commitment
- Half-assed Commitment
- Feigned Total Commitment
Of course, much like parents and teachers are expected by “the entrenched social system” to evaluate their children, but not vice-versa, this idea doesn’t have a chance of making it into the mainstream. Nevertheless, BD00 speculates that the practice is done somewhere as part of a continuous improvement initiative?
Pragmatic?
Still Applicable Today
Note: This graphic was clipped out of Bill Livingston’s D4P4D.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 