Archive

Posts Tagged ‘design’

Meet RAID And DIRA

November 29, 2014 Leave a comment

If you’re a C++ programmer, you’ve surely written code in accordance with the RAII (Resource Acquisition Is Initialization) idiom. Inspired by the RAII acronym, BD00 presents the RAID idiom: Requirements Allocation Is Design…

RAID

In order to allocate requirements to a design, you must have a design in mind that you think satisfies those requirements. Circularly speaking, in order to create a design (like the one above), you must have a set of requirements in mind to fuel your design process. Thus, RAID == DIRA (Design Is Requirements Allocation).

RAID DIRA

On Complexity And Goodness

May 21, 2014 4 comments

While browsing around on Amazon.com for more books to read on simplicity/complexity, the pleasant memory of reading Dan Ward’s terrific little book, “The Simplicity Cycle“, somehow popped into my head. Since it has been 10 years since I read it, I decided to dig it up and re-read it.

In his little gem, Dan explores the relationships between complexity, goodness, and time. He starts out by showing this little graph, and then he spends the rest of the book eloquently explaining movements through the complexity-goodness space.

Complexity Vs Goodness

First things first. Let’s look at Mr. Ward’s parsimonious definitions of system complexity and goodness:

Complexity: Consisting of interconnected parts. Lots of interconnected parts equal high degree of complexity. Few interconnected parts equal a low degree of complexity.

Goodness: Operational functionality or utility or understandability or design maturity or beauty.

Granted, these definitions are just about as abstract as we can imagine, but (always) remember that context is everything:

The number 100 is intrinsically neither large nor small. 100 interconnected parts is a lot if we’re talking about a pencil sharpener, but few if we’re talking about a jet aircraft. – Dan Ward

When we start designing a system, we have no parts, no complexity (save for that in our heads), no goodness. Thus, we begin our effort close to the origin in the complexity-goodness space.

As we iteratively design/build our system, we conceive of parts and we connect them together, adding more parts as we continuously discover, learn, employ our knowledge of, and apply our design expertise to the problem at hand. Thus, we start moving out from the origin, increasing the complexity and (hopefully!) goodness of our baby as we go. The skills we apply at this stage of development are “learning and genesis“.

At a certain point in time during our effort, we hit a wall. The “increasing complexity increases goodness” relationship insidiously morphs into an “increasing complexity decreases goodness” relationship. We start veering off to the left in the complexity-goodness space:

Decreasing Goodness

Many designers, perhaps most, don’t realize they’ve rotated the vector to the left. We continue adding complexity without realizing we’re decreasing goodness.

We can often justify adding new parts independently, but each exists within the context of a larger system. We need to take a system level perspective when determining whether a component increases or decreases goodness. – Dan Ward

Once we hit the invisible but surely present wall, the only way to further increase goodness is to somehow start reducing complexity. We can do this by putting our “learning and genesis” skills on the shelf and switching over to our vastly underutilized “unlearning and synthesis” skills. Instead of creating and adding new parts, we need to reduce the part count by integrating some of the parts and discarding others that aren’t pulling their weight.

Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away. – Antoine de Saint Exupery

Dan’s explanation of the complexity-goodness dynamic is consistent with Joseph Tainter’s account in “The Collapse Of Complex Societies“. Mr. Tainter’s thesis is that as societies grow, they prosper by investing in, and adding layer upon layer, of complexity to the system. However, there is an often unseen downside at work during the process. Over time, the Return On Investment (ROI) in complexity starts to decrease in accordance with the law of diminishing returns. Eventually, further investment depletes the treasury while injecting more and more complexity into the system without adding commensurate “goodness“. The society becomes vulnerable to a “black swan” event, and when the swan paddles onto the scene, there are not enough resources left to recover from the calamity. It’s collapse city.

The only way out of the runaway increasing complexity dilemma is for the system’s stewards to conscientiously start reducing the tangled mess of complexity: integrating overlapping parts, fusing tightly coupled structures, and removing useless or no-longer-useful elements. However, since the biggest benefactors of increasing complexity are the stewards of the system themselves, the likelihood of an intervention taking place before a black swan’s arrival on the scene is low.

 

Complexity ROI

At the end of his book, Mr. Ward presents a few patterns of activity in the complexity-goodness space, two of which align with Mr. Tainter’s theory. Perhaps the one on the left should be renamed “Collapse“?

CG Patterns

 

So, what does all this made up BD00 complexity-goodness-collapse crap mean to me in my little world (and perhaps you)? In my work as a software developer, when my intuition starts whispering in my ear that my architecture/sub-designs/code are starting to exceed my capacity to understand the product, I fight the urge to ignore it. I listen to that voice and do my best to suppress the mighty, culturally inculcated urge to over-learn, over-create, and over-complexify. I grudgingly bench my “learning and genesis” skills and put my “unlearning and synthesis” skills in the game.

Faking Rationality

November 24, 2012 8 comments

I recently dug up and re-read the classic Parnas/Clement 1986 paper: “A Rational Design Process: How And Why To Fake It“. Despite the tendency of people to want to desperately believe the process of design is “rational“, it never is. The authors know there is no such thing as a sequential, rational design process where:

  • There’s always a good reason behind each successive design decision.
  • Each step taken can be shown to be the best way to get to a well defined goal.

The culprit that will always doom a rational design process is “learning“:

Many of the details only become known to us as we progress in the implementation (of a design). Some of the things that we learn invalidate our design and we must backtrack (multiple times during the process). The resulting design may be one that would not result from a rational design process. – Parnas/Clements

Since “learning“, in the form of going backwards to repair discovered mistakes, is a punishable offense in social command & control hierarchies where everyone is expected to know everything and constantly march forward, the best strategy is to cover up mistakes and fake a rational design process when the time comes to formally present a “finished” design to other stakeholders.

Even though it’s unobtainable, for some strange reason, Spock-like rationality is revered by most orgs. Thus, everyone in org-land plays the “fake-it” game, whether they know it or not. To expect the world to run on rationality is irrational.

Executives preach “evidence-based decision-making“, but in reality they practice “decision-based evidence-making“.

Fish On Fridays III

March 16, 2012 Leave a comment

It’s Friday, so it’s time to eat some more fish. Guest blogger “fishmeister” has fried up another tasty treat for you and me to savor.

Firefighter or Fire-proofer: The Tyranny of Today

Software coder.  Designer.  Thinker.

In those jobs, your primary purpose is to take a blank page and fill it with something that solves an identified problem or need. Often, this requires a great deal of cognitive thinking–noodling out an idea ahead of any actual work.  And this takes time.

Unlike a laborer, who’s efforts are immediately apparent as their manual activities produce something tangible, cognitive thinking does not take place on a schedule. You can’t just sit down and say “at 10:30 on Tuesday, I’m going to have a brilliant thought“. It takes time. Sometimes lots of time. And sometimes it happens at odd times when you least expect it.

That ‘eureka moment’ can happen in the car, in the shower, at your desk, in line for coffee–anywhere, anytime. Which brings me to the real reason for this post.

If your work time is spent on putting out fires and solving immediate issues at the expense of thinking strategically about long-term solutions–innovation–you end up getting stuck in the Tyranny of Today–being a fireman instead of a fire-proofer.

Jeffrey Phillips writes a blog that I follow regularly. (BD00’s humble writings and Jeffrey’s are #1 and #2 on my daily morning reading list).  ((I won’t say in which order, though)). 🙂

The other day he wrote about The Tyranny of Today. It resonated with me on so many levels that I had to share it with my boss. He outlines everything that we are currently struggling with in our business every day.

We have a large cadre of Designers in our organization, yet we are always being challenged because we don’t think ‘creatively‘. Our deadlines are short–sometimes less than a day between being given a project and expecting a solution to be generated. This creates a dilemma that up until now, I didn’t quite understand.  Mr. Phillips puts it most succinctly…

…[The tyranny of today is] An “all hands on deck” mentality, which means that all available resources are focused on today’s issues, today’s needs, today’s problems. Ever more efficient operating models have pared organizations to the bone, meaning that anyone not working on today’s issues seem superfluous. Until the new products and services cupboard is bare because no one was working on new products and services.

We’ve created very powerful “business as usual” engines, and increasingly, these engines no longer serve us, we serve them. The BAU models dictate how we think, how we deploy resources and how we reward people. The tyranny of today is based on our business as usual operating models and the perverted ways in which they drive our strategies, our thinking and the way we apply resources.

We live in an immediate-gratification society these days. Technologies surrounding us have been developed to speed up the processes required to get things done. Back when “I was a kid” designer, developing a concept meant several days of pencil sketches, thumbnails, doodling, and eventually working out a refined concept, that required an artistic skill to draw, paint, and color in a visual representation of an idea up to a sufficient level that someone else (with the purse-strings) would be willing to shell out cash for your idea. All this effort meant that you were “off-line” for any other projects that came along, and as a result, the # of Designers and Freelancers in our studio would increase or decrease based on the workload at the time.

These days, I can bang out a 3-dimensional computer model–complete with textures, surfaces, lighting, and visuals–that looks so convincing that you’d think I’d just taken a picture of a real object in the real world. And I can do this in less than an hour. The tech around me has allowed the mechanical process of simulation to occur at the click of a mouse. But my brain still works the same old way.

At the same time, the down economy has meant that we’ve been cutting back on personnel, letting Designers go and not refilling those positions immediately. Those remaining have to just pick up the load. (“Leveraging resources” is the euphemism we hear every day.) Which means that we rely on our tech to an even greater degree just to get today’s workload completed.

As a result, we have bursts where there is more work that is due right now, than we have bodies in place to handle. Which means that in order to get it all done, I have to take off my propeller-equipped beanie hat and put on my fireman’s helmet. And with all the immediate issues of short-term needs–the fires that take place every day-I put out those fires and sacrifice the time needed to think creatively on another project. I become a victim of the Tyranny of Today.

How about you–do you spend your day sitting under an apple tree waiting for the fruit to smack you on your noggin, or do you piss on fires all day? What can you do in your business to escape the pattern and grow?

A Thing In Context

January 11, 2012 2 comments

Fierce Protection

December 6, 2010 4 comments

Delicious, just delicious. Pitches from Fred Brooks, Scott Berkun, Tom DeMarco, Tim Lister, and Steve McConnell all in one place:  the Construx (McConnell’s company) Software Executive Summit. You can download them from here:  Summit Materials.

Here’s a snapshot of one of Fred Brooks’s slides that struck me as paradoxical:

So…. who’s the “we” that Fred is addressing here and what’s the paradox? I’m pretty sure that Fred is addressing managers, right? The paradox is that he’s admonishing managers to protect great designers from…… managers. WTF?

But wait, I think I get it now. Fred is telling PHOR managers to “fiercely” protect designers from Bozo Managers (but in a non-offensive and politically correct way, of course). Alas, the fact that this slide appears at all in Fred’s deck implies that PHORs are rare and BMs are plentiful, no?

How do you interpret this slide?

Disambiguation Text Boxes

October 23, 2010 Leave a comment

If you believe that 2D or 3D graphical models reveal more about a system than pure 1D  text models, then graphics should be the  primary means of communication for complex structural and behavioral  information, no? Nevertheless, sequential text annotations can be an important secondary contributor to the transmission of meaning and understanding via graphics. A skillful combination of graphics plus text  is best, dontcha think?

Graphical notations, while important and useful, aren’t sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. – The GoF

DTBs, or Disambiguation Text Boxes (a.k. a. notes, legends), can be used to help fill in some of the subtle gaps in understanding that graphics alone cannot disclose/convey to people who need to deeply understand the message/content of what you’re trying to say. DTBs can contain full sentences or just phrases and acronyms; whatever it takes to help your readers extract whatever meaning and understanding they need to do their jobs better. And you do want to help others, no?

The figures below show some examples of attempts to use DTBs to help readers understand and make meaning from graphics models. Of course, graphics and text models can’t and shouldn’t totally replace physical human-to-human interaction, but they can lessen the required frequency of face to face communication and reduce errors when face to face meetings do occur, right?

%d bloggers like this: