Posts Tagged ‘systems’

Abstract Decomposition And Concrete Composition

November 6, 2014 1 comment

On the left we have the process of abstract decomposition, and on the right we have the process of concrete composition:

Decompose And Compose

Note that during the concrete composition from parts to final system on the right, we gracefully transition through two stable, intermediate forms. Some people and communities, especially those obsessed with “velocity” and “time-to-market“, would say “bollocks” to all those value-subtracting, intermediate steps. We no need no stinking intermediate  forms:

direct composition





A Skeptical “No”

May 5, 2014 7 comments

Just about every agile video, book, and article I’ve ever consumed assumes some variant of the underlying team model shown below. The product these types of teams build is comprised of custom software running on off-the-shelf server hardware. Even though it’s not shown, they also assume a client-server structure, request-response protocol, database-centric system.

SW only

The team model for the types of systems I work on is given below. They are distributed real-time event systems comprised of embedded, heterogeneous, peer processors glued together via a pub-sub protocol. By necessity, specialized, multi-disciplinary teams are required to develop this category of systems. Also, by necessity, the content of the sprint backlog is more complex and intricately subtler than the typical agile IT product backlog of “features” and “user stories“.

SW and HW

When I watch/read/listen to smug agile process experts and coaches expound the virtues of their favorite methodology using narrow, anecdotal, personal stories from the database-centric IT world, I continuously ask myself “can this apply to the type of products I help build?“. Often, the answer is a skeptical “no“. Not always, but often.

A Danger To Themselves And Others

May 16, 2013 3 comments

“Efficient systems are dangerous to themselves and others” – John Gall

A new system is always established with the goal of outright solving, or at least mitigating, a newly perceived problem that can’t be addressed with an existing system. As long as the nature of the problem doesn’t change, continuously optimizing the system for increased efficiency also joyfully increases its effectiveness.

However, the universe being as it is, the nature of the problem is guaranteed to change and there comes a time where the joy starts morphing into sorrow. That’s because the more efficient a system becomes over time, the more rigid its structure and behavior becomes and the less open to change it becomes. And the more resistant to change it becomes, the more ineffective it becomes at achieving its original goal – which may no longer even be the right goal to strive for!

Eff vs Eff

In the manic drive to make a system more efficient (so that more money can be made with less effort), it’s difficult to detect when the inevitable joy-to-sorrow inflection point manifests. Most managers, being cost-reduction obsessed, never see it coming – and never see that it has swooshed by. Instead of changing the structure and/or behavior of the system to fit the new reality, they continue to tweak the original structure and fine tune the existing behaviors of the system’s elements to minimize the delay from input to output. Then they are confounded when (if?) they detect the decreased effectiveness of their actions. D’oh! I hate when that happens.

Thought Actual

Sensors AND Actuators


May 11, 2012 6 comments

I just received two copies of William Livingston’s “Design For Prevention For Dummies” (D4P4D) gratis from the author himself. It’s actually section 7 of the “Non-Dummies” version of the book. With the addition of  “For Dummies” to the title,  I think it was written explicitly for me. D’oh!

The D4P is a mind bending, control theory based methodology (think feedback loops) for problem prevention in the midst of powerful, natural institutional forces that depend on problem manifestation and continued presence in order to keep the institution alive.

Mr. Livingston is an elegant, Shakespearian-type writer who’s fun to read but tough as hell to understand. I’ve enjoyed consuming his work for over 25 years but I still can’t understand or apply much of what he says – if anything!

As I slowly plod through the richly dense tome, I’ll try to write more posts that disclose the details of the D4P process. If you don’t see anything more about the D4P from me in the future, then you can assume that I’ve drowned in an ocean of confusion.

Complementary Views

March 8, 2012 2 comments

One classic definition of a system is “a set of interacting parts that exhibits emergent behavior not attributable solely to one part“. An alternative, complementary definition of a system served up by Russell Ackoff is “a whole that is defined by its function in a larger system of which it is a part“.

The figure below models the first definition on the left and the second definition on the right. Neither is “righter” than the other. They, and I love saying this because it’s frustratingly neutral, “just are“.

Viewing a system of interest from multiple viewpoints provides the viewer with a more holistic understanding of the system’s what, how, and why. Problem diagnosis and improvement ideas are vastly increased when time is taken to diligently look at a system from multiple viewpoints. Sadly, due to how we are educated, the inculcated tendency of most people is to look at a system from a single, parochial viewpoint: “what’s in it for me?“.

A Thing In Context

January 11, 2012 2 comments

Get every new post delivered to your Inbox.

Join 471 other followers

%d bloggers like this: