Posts Tagged ‘state machine diagram’

The Unwanted State Transition

Humor me for a moment by assuming that this absurdly simplistic state transition diagram accurately models the behavior of any given large institution:

Culture STM

In your experience, which of the following transitions have you observed occurring most frequently at your institution?

management xitions

The BD00 Process

December 19, 2011 6 comments

I believe that human beings love personal stories and direct experiential reports. Thus, even though it’s highly proprietary and super secret, I’m going to expose the somewhat repeatable “process” that I use for whipping up dumbass blog posts.

Here’s how BD00 does the dirty deed…

  • Every morning, after going to bed between 8-9 PM, I wake up between 4-5 AM.
  • I fire up a pot of coffee and then sit down at the computer.
  • I navigate to the BD00 dashboard.
  • I mine “fieldstone” writing ideas from: my “gym notes“, my quotes pages, an interesting interaction or tainted observation at work, random web surfing, my kindle highlights, a twitter post.
  • I wait…..
  • A freakin’ miracle occurs!
  • I start writing words or drawing a picture, or both.
  • I chaotically jump back and forth ‘tween writing and drawing – iteration city.
  • Sometimes, I write some words, draw a picture, and then finish the words.
  • Sometimes, I write all the words first and then re-scan them for drawing ideas.
  • Sometimes, I draw a partial picture, write some words, and then I finish the pic.
  • Sometimes, I draw a complete picture first and then I write the words that go with it.
  • I iterate over the words + picture combo multiple times until…. I say “WTF, I’m done!

Of course, even though the BD00 process is expressed as a nice and tidy bulleted list above, it’s not a procedure. To highlight the non-sequential nature of the process, here’s the UML state machine diagram model:

Note the numerous initial entry points and that every state has an iterative transition “to self“. That’s because I Am A Strange Loop.

Requirements Stability

Over the years, I’ve been assigned to the roles of specifier, designer, documenter, writer, and maintainer of source code for radar sensor systems that are used in safety-critical applications. These sensors get deployed in noisy, interference-infested environments and they must perform at high levels of availability and with great fidelity.

The figure below shows a generic sensor system context diagram along with some typical non-functional requirements (with made-up values) that are critical for customer acceptance. My experience has indicated that once these black-box level requirements are specified, they rarely change. Thus, the agile war cry to continuously “embrace requirements change” may not fully apply to the development of this class of systems, no?

The point I’m trying to make here is to be wary of morphing into a lap-dog zealot for any technique, process, method, or practice – which includes the hallowed “agile” brand. For a long time, my motto (thanks to the work of W. L. Livingston and John Warfield) has been: Context, Content, and then Process (CCP). Synthesize an understanding of the problem context, design the content of the solution (structure and behavior), and only then design the solution construction process – tailored to the context and content. Of course, since mistakes and errors will be made during the journey, backtracking and iterative convergence are expected. Thus, “embrace mistakes, errors, backtracking, and iteration” is my war cry. What’s yours? What’s your org’s?

%d bloggers like this: