Archive
The Future Is Already Here…..
….for those people who are lucky enough to work in truly enlightened orgs that really walk the talk.
Check out this case study: “How Microsoft Netherlands Reinvented the Way of Work”. Yes, you read that right. It’s a division of that polarizing behemoth, Microsoft.
Just in case you don’t have the time, but you’d like the cliff-dozer00 notes version of the article’s highlights, here they are:
- There are no assigned desks as well as no private offices for managers (not even the General Manager).
- There are no physical “Departments”, each of the 900 employees of MS Netherlands can work anywhere in the office building by using a laptop, headset, webcam, or Windows based Smartphone and connecting to the network either wirelessly or by plugging in at a desk.
- People are encouraged to work from home more often, whenever it is appropriate and are allowed to work whatever times they wish to work. The only requirement is that they “get the job done”.
- If you wish to work until late at night on a project and take the morning to see your son’s school play, you can do that too – and you don’t have to ask your manager for the time off.
So, how can one judge whether these Theory Y policies have worked out? Managers love metrics (cuz metrics give them the illusion that they’re in control), so here are a few:
Of course, managers who who are dead set on clinging to their FOSTMA thinking UCBs (regardless of what they espouse) won’t believe the results; or they’ll play ostrich and ignore their existence – because it would take too much courage and “work” to effect a similar, massively positive change in their CCFs.
Truckin’
Truckin’ got my chips cashed in. Keep truckin’, like the do-dah man. – Grateful Dead
One of the funny concepts that someone concocted a while back is called the “truck number“. The truck number is the number of critical people on a project that would need to get hit by a truck (and die) before the project is guaranteed to get completely hosed.
A couple of ways to increase your truck number is to minimize specialization of roles and to effect job rotations in areas of expertise that aren’t orthogonal from each other. However, if you think of, and treat all of, the people on your project as quickly replaceable cogs, then you erroneously and naively assume that the truck number is equal to the number of people on your project. Thus, the bigger the project, the better. Whoo Hoo!
kkk
Pegged
Peg, It will come back to you – Steely Dan
Assume that as a sub-task of redesigning a BBoM chunk of legacy software for scalability (single thread to mutliple threads), you have to “do something” with a subset of high performance, but computationally dense and tricky, C procedural code. Let’s call the functionality implemented by this code “peg“.
In the figure below, I model the procedural mess that is “peg” on the left as an M function call tree in which many of the functions perform CRUD accesses on a set of K interrelated global data structures. Trust me when I say that K and M are non-trivial, double digit numbers. D’oh!
The way I see it, I have three choices for attacking the monolith:
Options 1 and 2 are slightly different instances of the ultra-conservative “sarcophagus” pattern (remember Chernobyl?). Option 3, which is technically riskier, higher latency, and higher development cost in the short term, will definitely pay off in terms of lower maintenance costs and lower developer anxiety the long term – if done correctly!
If it was my decision alone (and it should be since I’ll be doing all the coding/testing/documenting/defending/”owning“, no?), I’d choose option 3 without blinking an eye. I wouldn’t blink an eye because I know that “peg” will continue to need to be extended and enhanced for many years into the future – and maintenance costs far exceed initial developments costs in all software product life cycles. But alas, I’m just a dumb engineer with no business sense.
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?
The Ideal Quadrant
Zappos.com operates on the simple principle that happy people make productive workers and productive workers make a successful enterprise. Thus, the policies and cultural accoutrements instituted at Zappos.com are thoughtfully and proactively designed to foster happiness without totally abdicating control. For Zappos.com, it’s not enough to have a “competitive” benefits and pay package – everyone (still in business) has to have one.
With that in mind, let’s explore the four quadrants in the simplistic table below. Right off the bat, we can ditch the two quadrants in the second row. After all, no org can remain viable for very long with an unproductive workforce – regardless of whether the emps are happy. No?
So that leaves us with the two quadrants in the first row. One would think that the holy grail for excellence-seeking orgs is the Productive-And-Happy (PAH) quadrant. However, a multitude of circumstantial evidence leads me to believe that most orgs are either consciously or unconsciously incompetent at catalyzing the development of a PAH workforce – regardless of what is espoused in the annual report. The legions of enterprises that fall into the CLORGs and DYSCOs category don’t even make an effort to develop “happy” employees. The SCOLs that run the show are too macho and they delude themselves into thinking that happiness doesn’t matter or it’s “not in their job description“. Should it be?
What comes first, productivity or happiness? Is one attribute a pre-requisite for attaining the other?
The Urge To Surge
Man is a wanting animal – Peter Ralston
With over 700 published posts behind me, it was inevitable that my “false self” would start thinking about the possibility of publishing a book that would rocket to the top of the NY Times best seller list and bring me the fame, fortune, and care-free life that I deserve. Whoo hoo!
Because of this emerging, ego-centric, urge to surge, I recently registered with the Amazon.com “Kindle Direct Publishing” web site. However, I haven’t belly-flopped into the murky “how to” details that are thoughtfully explained at the site because every time I think about doing it, I have visions of spending an ungodly amount of time organizing, writing, editing, and prepping the book’s content. The real, deal-breaking excuse in my mind is how to freakin’ incorporate all the dorky graphics that I’ve generated into the Kindle form factor. If the book was gonna be purely text-based, maybe my anxiety and fear levels wouldn’t be so high. But then again, maybe they would.
Wax On, Wax Off
Hands on, hands off. I was trying to contemplate the reasons why some managers operate with “hands off” and here are three that I scribbled down at the gym…
Got any others?
Traceability Woes
For safety-critical systems deployed in aerospace and defense applications where people’s lives may at be at stake, traceability is often talked about but seldom done in a non-superficial manner. Usually, after talking up a storm about how diligent the team will be in tracing concrete components like source code classes/functions/lines and hardware circuits/boards/assemblies up the spec tree to the highest level of abstract system requirements, the trace structure that ends up being put in place is often “whatever we think we can get by with for certification by internal and external regulatory authorities“.
I don’t think companies and teams willfully and maliciously screw up their traceability efforts. It’s just that the pragmatics of diligently maintaining a scrutable traceability structure from ground zero back up into the abstract requirements cloud gets out of hand rather quickly for any system of appreciable size and complexity. The number of parts, types of parts, interconnections between parts, and types of interconnections grows insanely large in the blink of an eye. Manually creating, and more importantly, maintaining, full bottom-to-top traceability evidence in the face of the inevitable change onslaught that’s sure to arise during development becomes a huge problem that nobody seems to openly acknowledge. Thus, “games” are played by both regulators and developers to dance around the reality and pass audits. D’oh!
To illustrate the difficulty of the traceability challenge, observe the specification tree below. During the development, the tree (even when agile and iterative feedback loops are included in the process) grows downward and the number of parts that comprise the system explodes.
In “theory” as the tree expands, multiple traceability tables are rigorously created in pay-as-you-go fashion while the info and knowledge and understanding is still fresh in the minds of the developers. When “done” (<- LOL!), an inverse traceability tree with explicit trace tables connecting levels like the example below is supposed to be in place so that any stakeholder can be 100% certain that the hundreds of requirements at the top have been satisfied by the thousands of “cleanly” interconnected parts on the bottom. Uh yeah, right.
SysML Support For Requirements Modeling
“To communicate requirements, someone has to write them down.” – Scott Berkun
Prolific author Gerald Weinberg once said something like: “don’t write about what you know, write about what you want to know“. With that in mind, this post is an introduction to the requirements modeling support that’s built into the OMG’s System Modeling Language (SysML). Well, it’s sort of an intro. You see, I know a little about the requirements modeling features of SysML, but not a lot. Thus, since I “want to know” more, I’m going to write about them, damn it! 🙂
SysML Requirements Support Overview
Unlike the UML, which was designed as a complexity-conquering job performance aid for software developers, the SysML profile of UML was created to aid systems engineers during the definition and design of multi-technology systems that may or may not include software components (but which interesting systems don’t include software?). Thus, besides the well known Use Case diagram (which was snatched “as is” from the UML) employed for capturing and communicating functional requirements, the SysML defines the following features for capturing both functional and non-functional requirements:
- a stereotyped classifier for a requirement
- a requirements diagram
- six types of relationships that involve a requirement on at least one end of the association.
The Requirement Classifier
The figure below shows the SysML stereotyped classifier model element for a requirement. In SysML, a requirement has two properties: a unique “id” and a free form “text” field. Note that the example on the right models a “non-functional” requirement – something a use case diagram wasn’t intended to capture easily.
One purpose for capturing requirements in a graphic “box” symbol is so that inter-box relationships can be viewed in various logically “chunked“, 2-dimensional views – a capability that most linear, text-based requirements management tools are not at all good at.
Requirement Relationships
In addition to the requirement classifier, the SysML enumerates 6 different types of requirement relationships:
A SysML requirement modeling element must appear on at least one side of these relationships with the exception of <<derivReqt>> and <<copy>>, which both need a requirement on both sides of the connection.
Rather than try to write down semi-formal definitions for each relationship in isolation, I’m gonna punt and just show them in an example requirement diagram in the next section.
The Requirement Diagram
The figure below shows all six requirement relationships in action on one requirement diagram. Since I’ve spent too much time on this post already (a.k.a. I’m lazy) and one of the goals of SysML (and other graphical modeling languages) is to replace lots of linear words with 2D figures that convey more meaning than a rambling 1D text description, I’m not going to walk through the details. So, as Linda Richman says, “tawk amongst yawselves“.
References
1) A Practical Guide to SysML: The Systems Modeling Language – Sanford Friedenthal, Alan Moore, Rick Steiner
2) Systems Engineering with SysML/UML: Modeling, Analysis, Design – Tim Weilkiens
No Golf?
While reading about the rise of the Google juggernaut in Steven Levy‘s “In The Plex“, I stumbled upon this jaw dropping passage:
WTF? No sponsored golf? Bummer.
Note: The main purpose of this post wasn’t really to joke about the lack of golf outings sanctioned at Google. It was to make sure that you, dear readers, saw the “coddling” sentence. In CLORGs and DYSCOs that have lost their way, and Google may eventually morph into one of these monstrosities; salesman, marketers and managers coddle themselves and their incest-born kin more than the bottom line wealth and value creators; be they artists, ad-creators, plumbers, electricians, doctors, nurses, system engineers, software engineers, test engineers, and/or hardware engineers. But hey, don’t listen to me. I have an ego-maniacal agenda – just like the roles I condemn.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 