Archive
Broken, Not Bent
It’s one thing to “bend” the UML to express a design concept that you don’t know how to express with the language, but it’s another thing to “break” it outright. By “break“, I mean drawing old-school, ad-hoc, single-symbol diagrams that all look alike and passing them off as UML class, deployment, activity, etc, diagrams.
By propagating broken UML diagrams out into the world in a sincere, but fruitless, attempt to establish a shared understanding among team members, the exact opposite can occur – mass confusion and an error prone, friction-filled development effort. Even worse, presenting the ad-hoc quagmire to customers and financiers who have a rudimentary education in object orientation and UML can cause them to question the competence of the presenters and the wisdom of their investment choice.
But hey, there’s nothing to worry about. Nobody understands or cares about the UML anyway. Thus, the ambiguity, inconsistency, and conflicts inherent in the design won’t be exposed (or ever traced-back-to) if schedule and cost disaster strikes.
All models are wrong. Some, however, are useful. – George E. Box
Related articles
- Proprietary Extensions (bulldozer00.com)
- UML Tool for Fast UML Diagrams (allincircles.wordpress.com)
- Mind Maps: The Poor Man’s Design Tool (drdobbs.com)
Scrum And Non-Scrum Interfaces
According to the short and sweet Schwaber/Sutherland Scrum Guide, a Scrum team is comprised of three, and only three, simple roles: the Product Owner, the Scrum Master, and the Developers. One way of “interfacing” a flat and collaborative Scrum team to the rest of a traditional hierarchical organization is shown below. The fewer and thinner the connections, the less impedance mismatch and the greater the chances of efficient success.
Regarding an ensemble of Scrum Developers, the guide states:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
I think (but am not sure) that the unambiguous “no exceptions” clause is intended to facilitate consensus-based decision-making and preclude traditional “titled” roles from making all of the important decisions.
So, what if your conservative org is willing to give Scrum an honest, spirited, try but it requires the traditional role of “lead(s)” on teams? If so, then from a pedantic point of view, the model below violates the “no exceptions” rule, no? But does it really matter? Should Scrum be rigidly followed to the letter of the law? If so, doesn”t that demand go against the grain of the agile philosophy? When does Scrum become “Scrum-but“, and who decides?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Bring Back The Old (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- From Complexity To Simplicity (bulldozer00.com)
- Why I’m done with Scrum (lostechies.com)
Zero Experience
If you look at the “Categories” box on the right side of this blawg page, you’ll see that the number of posts categorized as “management” is much larger than any other category. However, except for 4 years of serving as a software “lead” on two different projects, BD00 has zero management experience over his un-illustrious career-end. Nada, zilch, the big goose egg.
So, you ask: “What gives BD00 the right to write about management practices and behaviors?” My good buddy and intellectual inferior, Mr. Albert Einstein, says it best in “Essays In Humanism“:
Many readers may ask: “What right has he to speak out about things which concern us alone, and which no newcomer should touch?” I do not think such a standpoint is justified. One who has grown up in an environment takes much for granted. On the other hand, one who has come to this country as a mature person may have a keen eye for everything peculiar and characteristic. I believe he should speak out freely on what he sees and feels, for by so doing he may perhaps prove himself useful.
Except for maybe the “mature” and “…for by so doing he may perhaps prove himself useful” parts, that’s one of the reasons why I do it. Another is that I’d love to see the guild move much more quickly toward what Gary Hamel calls “Management 2.0” instead of languishing in its 2oth century, self-serving creation.
Dummkopf
I received this e-mail ad yesterday and felt a burning need (which will not be articulated) to post it on this bogus blog:
Shhhhhh! Don’t tell anyone, but I’m a fan of the “Dummies” series because…. I am a freakin’ Dummkopf. The first book I ever studied on C++ was “C++ For Dummies“. Double-Shhh!!!!
If you stumble across a “Software Engineering For Dummies” book, please notify me. Even better, keep a lookout for a “Software Engineering For Idiots” book.
Note: Since the links in jpg images don’t work, here’s the link you want to click, if you do indeed want to click it: Systems Engineering for Dummies – Effective Application Lifecycle Management Solutions Lab. Don’t worry, I won’t tell anyone. Mum’s the word.
He Said, He Thought, He Said, He Thought
In “Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing–and Focus on What Really Matters“, Sam Culbert provides several, made-up, boss-subordinate exchanges to make his case for jettisoning the archaic, 1900’s “annual performance review“. For your reading pleasure, I lifted one of these depressingly funny exchanges out of the book and transformed it into a derivation of Chris Argyris’s terrific LHS-RHS format. It’s long, and it took me a bazillion years to recreate it on this stupid-arse blawg; so please read the freakin’ thing.
Did you notice how both the boss and the subordinate suffered from the ordeal? But of course, you don’t have to worry about experiencing similar torture because the “annual performance review” at your institution is different. Even better, your org has moved into the 21st century by implementing an alternative, more equitable and civilized way of gauging performance and giving raises.
In his hard-hitting and straight-talking book, Mr. Culbert, a UCLA management school professor and industry consultant firebrand (he’s got street cred!), really skewers C-level management. He fires his most devastating salvos at evil HR departments for sustaining the “annual performance review” disaster that sucks the motivation out of everybody within reach. And yes, he does provide viable alternatives (that won’t ever be implemented in established, status-quo-loving borgs) to HR’s beloved “annual performance review“. Buy and read the book to find out what they are.
Note: Thanks Elisabeth, for steering me toward Mr. Culbert’s blasphemous work. It has helped to reinforce my entrenched UCB and the self-righteous illusion that “I’m 100% right“. But wait! I’m not allowed to be right.
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“?
Temporary Enlightenment
Non-Compliance
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?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 