Archive
Irritated
Unsurprisingly, one of BD00’s posts irritated a reader who stumbled upon it. For some strange reason, BD00’s scribblings have that effect on some people. In the irritating post, “The Old Is New Again“, BD00 referred to Data and Control Flow diagrams as “old and obsolete“. In caustic BD00 fashion, the reader commented:
Use Cases and Activity Diagrams, in contrast (to the Data Flow diagram), offer little guidance in effective partitioning. They rely upon the age old “sledge hammer” approach to partitioning” (ie, just break-er-up any way you can). Sledge hammer partitioning is what cave men used to partition entities. So in a critical sense, DFD’s are new and hip, while Use Cases and Activity Diagrams are based upon logic that is older than dirt.
BD00 likes all visual modeling tools – including the DFD hatched during the heyday of structured analysis. BD00 only meant “old and obsolete” in the sense that DFDs pre-dated the arrival of the UML and the object-oriented approach to system analysis and design. However, BD00 did feel the need to correct the reader’s misunderstanding of the features and capabilities that UML Activity Diagrams offer up to analysts/designers.
Both the DFD and UML activity diagram pair below equivalently capture an analyst’s partitioning design decision (where DFD Process X == Activity Diagram Action X). Via “swimlanes“, the lower activity diagram makes the result of a second design decision visible: the conscious allocation of the Actions to the higher level Objects that will perform them during system operation. So, how are UML activity diagrams inferior to DFDs in supporting partitioning? A rich palette of other symbols (forks, joins, decisions, merges, control flows, signals) are also available to analysts (if needed) for capturing design decisions and exposing them for scrutiny.
DFDs and UML diagrams are just tools – job performance aids. Learning how to use them, and learning how to use them effectively, are two separate challenges. Design “guidance” for system partitioning, leveling, balancing, etc, has to come from somewhere else. From a mentor? From personal experience learning how to design systems over time? From divine intervention?
It’s The Relationships, Stupid
If you read Sam Culbert’s book rant against the taken-for-granted and unassailable “annual performance review” process, you’d think he is an anti-hierarchy revolutionary deserving to be crushed. But the dude is not:
Hierarchical structure, in the form of an organization chart, serves many constructive purposes. By showing the chain of command, it allows everyone to see who is responsible for what, how organization units are being deployed, and, most importantly, who should be accountable for bottom-line results. In contrast, I can’t think of a single constructive purpose served by hierarchical relationships— that is, those in which the boss gets to dominate all conversations.
Culbert, Samuel A. (2010-04-01). Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing–and Focus on What Really Matters (Business Plus) (pp. 128-129). Hachette Book Group. Kindle Edition. – Sam Culbert
In a man-made conceptual hierarchical breakdown of a tree’s “parts“, the relationships between the parts have nothing to do whatsoever with their “position” in the hierarchy. A tree’s components miraculously work together in synchronous harmony to manifest and share its beauty as a whole with all of nature – including us (perhaps undeserving) humans. Leaves aren’t pitted against leaves for the purpose of gaining more hierarchical status in the “minds” of the other tree parts. The trunk doesn’t perceive itself as “more important and deserving” than the “lowly” branches. The roots don’t talk about the topmost branches in a derogatory manner, nor vice versa.
Related articles
- He Said, He Thought, He Said, He Thought (bulldozer00.com)
The Real Customer
In “12 ‘best practices’ IT should avoid at all costs”, InfoWorld‘s Bob Lewis asserts:
I enjoy Bob’s books and columns, but I have to side with the likes of Russell Ackoff and Vineet Nayar on this one. All of an org’s “enabling” functions: HR, QA, Finance, Purchasing, IT, etc; should indeed serve the direct revenue-generating business functions and treat them as paying customers. Otherwise, the natural tendency of these groups in hierarchical orgs is to turn into obstacle-inserting, unresponsive, monopolistic dictatorships. Of course, in the “real world” this rarely happens because rational adults are in charge – and Bob is right. What is your opinion?
Bounded Solution Spaces
As a result of an interesting e-conversation with my friend Charlie Alfred, I concocted this bogus graphic:
Given a set of requirements, the problem space is a bounded (perhaps wrongly, incompletely, or ambiguously) starting point for a solution search. I think an architect’s job is to conjure up one or more solutions that ideally engulf the entire problem space. However, the world being as messy as it is, different candidates will solve different parts of the problem – each with its own benefits and detriments. Either way, each solution candidate bounds a solution space, no?
Methodology Taxonomy
Here’s a feeble attempt at sharing a taxonomy of well-known (to BD00) software development methodologies:
Got any others to add to revision 1? How about variations on the hated “WATERFALL!” class? Where should the sprawling RUP go? What about “Scrum-but“? Does “kanban” fit into this taxonomy, or is it simply a practice to be integrated within a methodology? What about “Lean“?
Berkunated
A left uppercut to the jaw (ouch!), a right jab to the kisser (D’oh!), a left hook to the kidney (Blech!). I’ve just been Berkunated and I’m down for the count – yet again!
I just finished reading Scott Berkun’s fourth book, “Mindfire: Big Ideas for Curious Minds“. It was as delightfully painful to read as the other three of his books that I’ve read. Here’s what I mean by “delightfully painful“:
Was it as delightfully painful for you as it was for me? Got a cigarette?
Bedeviled
I don’t know about you, but this quote seems magical to me:
So, in the midst of the relentless erosion of integrity of all matter over time, how in the hell does anything ever get organized in the first freakin’ place? While something is being created in real-time, be it you or me or our own creations, the 2nd law of thermo is magically suspended from doing its damage.
It takes “work” to create something. As soon as the entropy-defying work stops, the disintegration of that something begins.
Dependence Over Autonomy
Matthew Gill’s “Accountant’s Truth” provides a fascinating analysis and expose of the attitudes and culture of the accounting industry through a series of in-depth interviews with practicing accountants. As I’m reading the book, I’m using the Kindle’s marvelous “share” feature to tweet snippets like this one out into the ether:
Now, compare this excerpt with the following pair of tweets from one of my fave spiritual teachers, Byron Katie:
Interesting, don’t you think?
Proprietary Extensions
When using a tool or technology that implements a universal standard, beware of inadvertently using non-standard extensions that “lock” you into the vendor’s revenue stream.
The graphic below shows a screenshot from Artisan Real-time Studio version 7.2. Even though the tool implements the UML 2.0 standard, notice that there are several “non-UML” diagrams that you can create: “Constraint Diagram“, “General Flow Diagram“, etc. If you choose to create and use these proprietary extensions, then you’re sh*t out of luck if you get pissed off at Atego and want to port your model over to a different UML tool vendor with a better and/or less expensive solution. D’oh! I hate when that happens.
I’m not trying to single out Atego here. Every commercial vendor, especially of expensive tools, bakes-in a few proprietary extensions to give them an edge over the competition. The sneakier ones don’t annotate or make obvious which features are proprietary – so beware.
Rules Of Thumb
Look what I dug up in my archives:
Hopefully, this list may provide some aid to at least one poor, struggling soul out in the ether.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 