Archive
The BD00 Process
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 wordpress.com 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.
Attack And Advance
Check out this recent Grady Booch tweet on the topic of “why” he, James Rumbaugh, and Ivar Jacobson syntegrated their individual modeling technologies into what became the UML standard:
Over 20+ years ago, when the rate of global change was just a mere inkling of what it is today, my friend Bill Livingston stated in HFAW that: “complexity has a bright future“. He was right on the money and I admire people like Bill and the three UML amigos for attacking complexity (a.k.a ambiguity) head-on – especially when lots of people seem to love doing the exact opposite – piling complexity on top of complexity.
Extreme complexity may not be vanquishable, but (I think) it can be made manageable with the application of abstract “systems thinking” styles and concrete tools/techniques/processes created by smart and passionate people, no?
Levels, Components, Relationships
In the Crosstalk Journal, Michael Tarullo has written a nice little article on documenting software architectures. Using the concept of abstract levels (a necessary, but not sufficient tool, for understanding complex systems) and one UML component diagram per level, he presents a lightweight process for capturing big software system architecture decisions out of the ether.
Levels Of Abstraction
Mr. Tarullo’s 5 levels of abstraction are shown below (minor nit: BD00 would have flipped the figure upside down and shown the most abstract level (“Global“) at the top.
Components Within A Level
Since “architecture” focuses on the components of a system and the relationships between them, Michael defines the components of concern within each of his levels as:
(minor nit: because the word “system” is too generic and overused, BD00 would have chosen something like “function” or “service” for the third level instead).
Relationships
Within a given level of abstraction, Mr. Tarullo uses a UML component diagram with ports and ball/socket pairs to model connections, interfaces (provides/requires), and to bind the components together. He also maintains vertical system integrity by connecting adjacent levels together via ports/balls/sockets.
The three UML component diagrams below, one for each of the top, err bottom, three levels of abstraction in his taxonomy, nicely illustrate his lightweight levels plus UML component diagram approach to software architecture capture.
But what about the next 2 levels in the 5 level hierarchy: the Application/Library and Classes levels of the architecture? Mr. Tarullo doesn’t provide documentation examples for those, but it follows that UML class and sequence diagrams can be used for the Application/Library level, while activity diagrams and state machine diagrams can be good choices for the atomic class level.
Providing and vigilantly maintaining a minimal, lightweight stack of UML “blueprint” diagrams like these (supplemented by minimal “hole-filling” text) seems like a lower cost and more effective way to maintain system integrity, visibility, and exposure to critical scrutiny than generating a boatload of DOD template mandated write-once-read-never text documents, no?
Alas, if:
- you and your borg don’t know or care to know UML,
- you and your borg don’t understand or care to understand how to apply the complexity and ambiguity busting concepts of “layering and balancing“,
- your “official” borg process requires the generation of write-once-read-never, War And Peace sized textbook monstrosities,
then you, your product, your customers, and your borg are hosed and destined for an expensive, conflict filled future. (D’oh! I hate when that happens.)
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 