Posts Tagged ‘state machine diagram’

The Dreaded SDFFR Acronym

January 11, 2022 1 comment

After being out of sorts for a bit, I’m back bloggin’ again cuz ya never know when the fit is gonna hit the shan. So, here’s a simple state machine model of BD00’s daily goal seeking behavior. The goal is to sequentially enter/exit each health-advancing state without experiencing an SDFFR event that triggers an early exit with a suboptimal daily physical health score (less than 3).

Here’s a scary graph of my dhs over the last several days.

Coming off of 3 straight 0 dhs scores due to SDFFR events precipitated by the Emperor, I was feeling really stressed about logging yet another goose egg day. But, as you can tell from the trace below, I thwarted the Emperor’s latest plan with a perfect Korbut 3. Today was a good day, a really good day.

Before exiting, I want to share some more recent Bitcoin Vandal crime scenes with you. The Emperor hates the Bitcoin Vandal too. He’s deployed his Orcs out in the field to hunt down the scoundrel.

Categories: bitcoin, Cancer Tags:

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: