Archive
Myopia And Hyperopia
Assume that we’ve just finished designing, testing, and integrating the system below:
Now let’s zoom in on the “as-built“, four class, design of SS2 (SubSystem 2). Assume its physical source tree is laid out as follows:
Given this design data after the fact, some questions may come to mind: How did the four class design cluster come into being? Did the design emerge first, the production code second, and the unit tests come third in a neat and orderly fashion? Did the tests come first and the design emerge second? Who gives a sh-t what the order and linearity of creation was, and perhaps more importantly, why would someone give a sh-t?
It seems that the TDD community thinks the way a design manifests is of supreme concern. You see, some hard core TDD zealots think that designing and writing the test code first ala a strict “red-green-refactor” personal process guarantees a “better” final design than any other way. And damn it, if you don’t do TDD, you’re a second class citizen.
BD00 thinks that as long as refactoring feedback loops exist between the designing-coding-testing efforts, it really doesn’t freakin’ matter which is the cart and which is the horse, nor even which comes first. TDD starts with a local, myopic view and iteratively moves upward towards global abstraction. DDT (Design Driven Test) starts with a global, hyperopic view and iteratively moves downward towards local implementation. A chaotic, hybrid, myopia-hyperopia approach starts anywhere and jumps back and forth as the developer sees fit. It’s all about the freedom to choose what’s best in the moment for you.
Notice that TDD says nothing about how the purely abstract, higher level, three-subsystem cluster (especially the inter-subsystem interfaces) that comprise the “finished” system should come into being. Perhaps the TDD community can (should?) concoct and mandate a new and hip personal process to cover software system level design?
Performance Meters
The figure below shows two types of performance evaluation systems; one that measures individual performance and the other which measures team performance.
Even though the figure implies a causal connection between type of measurement system and quality of team output, as usual, I have no idea if a causal relationship exists. I suspect they are statistically correlated though, and the correlation is indeed as shown. I think the system on the left encourages intra-team competition whereas the system on the right catalyzes intra-team cooperation. What do you think?
An Undefinable Relationship?
Checkout this model of a one person business:
The worker/manager/owner applies her tools, skills, and expertise to transform business ideas into outputs that a customer willingly pays for.
After composing the picture, it occurred to BD00 to attempt to explore the relationship ‘tween “Quality Of Output” (QOO) and time “Delay“. However, he drew a blank. He can’t proclaim that increasing delay generally increases QOO. Nor can he assert that decreasing delay generally decreases QOO. The only thing he can confidently state is: “since zero delay by definition means zero output, it also means zero QOO“. Well, duh!
Durable, Resilient, Adaptable
I really love this elegantly written paragraph by Stewart Brand:
The combination of fast and slow components makes the system resilient, along with the way the differently paced parts affect each other. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power. All durable dynamic systems have this sort of structure; it is what makes them adaptable and robust. – Clock Of The Long Now – Stewart Brand
If you think about organizations, the people at the bottom of the hierarchy should be the fast components that instruct and inform the slow controlling components at the top, no? However, if those at the top allow, or turn a blind eye to bureaucratic processes and procedures that impede quickness at the bottom, they’re screwing up big time, no? Requiring the builders dwelling in the cellar to jump through multiple, multi-layer review/approval cycles to purchase a 5 dollar part, or go to a conference, or get a custom, but simple, cable built, or add some useful code to a widely used library, can be considered an impediment, no?
Ninety percent of what we call ‘management’ consists of making it difficult for people to get get things done – Peter Drucker
If those at the top of a borg solely concern themselves with “the numbers“, bonuses for themselves, and rubbing elbows with other fellow biggies while the borg’s so-called support groups and middle managers stifle the builders with ever more red tape, then fuggedaboud having any fast components in the house. And if Mr. Brand is right in that resilient, durable, adaptable, learning systems require a mix of fast and slow components, then those at the top deserve the results they get from the unresilient, undurable, unadaptable, and unlearning borg they preside over.
Parallelism And Concurrency
In the beginning of Robert Virding’s brilliant InfoQ talk on Erlang, he distinguishes between parallelism and concurrency. Parallelism is “physical“, having to do with the static number of cores and processors in a system. Concurrency is “abstract“, having to do with the number of dynamic application processes and threads running in the system. To relate the physical with the abstract, I felt compelled to draw this physical-multi-core, physical-multi-node, abstract-multi-process, abstract-multi-thread diagram:
It’s not much different than the pic in this four year old post: PTCPN. It’s simply a less detailed, alternative point of view.
Game Changer
Even though I’m a huge fan of the man, I was quite skeptical when I heard Bjarne Stroustrup enunciate: “C++ feels like a new language“. Of course, Bjarne was talking about the improvements brought into the language by the C++11 standard.
Well, after writing C++11 production code for almost 2 years now (17 straight sprints to be exact), I’m no longer skeptical. I find myself writing code more fluidly, doing battle with the problem “gotchas” instead of both the problem and the language gotchas. I don’t have to veer off track to look up language technical details and easily forgotten best-practices nearly as often as I did in the pre-C++11 era.
It seems that the authors of the “High Integrity C++” coding standard agree with my assessment. In a white paper summarizing the changes to their coding standard, here is what they have to say:
Even though C++’s market niche has shrunk considerably in the 21st century, it is still widely used throughout the industry. The following chart, courtesy of Scott Meyers’ recent talk at Facebook, shows that the old-timer still has legs. The pending C++14 and C++17 updates virtually guarantee its relevance far into the future; just like the venerable paper clip and spring-loaded mouse trap.
Intellectual Understanding And Spiritual Realization
According to the late Sydney Banks and his “3 Principles” theory, the key to serenity and graceful living begins with an intellectual understanding and spiritual realization of the inseparable BIG THREE:
Graphic credits: Poached from Judy Sedgeman’s 3P web site
I can confidently say that I’ve acquired an intellectual understanding of the 3 principles, but I feel like some force is preventing me from realizing their spiritual power. I suspect that it’s BD00 working covertly behind the scenes to block that realization.
To further explore the elegant simplicity and potential transformative power of the 3P trinity, surf on over to the Three Principles Global Community web site and check out some of the videos and articles.
Banking On A Solution
This may be one of the main reasons why I’m skeptical of analytical experts and fascinated by the seemingly intractable coupling between complexity and simplicity:
Photo credit: Judy Sedgeman’s 3P web site
1D And 2D
In case you didn’t already know, I draw dorky diagrams often, really often. My motivation is to increase understanding by transforming a constricted, sequential, 1D word description of a new, interesting topic into a spatially loose, 2D visualization. To me, the resulting diagrams are not as important as the act of creating them. The iterative thinking and reflection required by the process anchors an understanding (which in fact may turn out to be wrong) in place. Maybe you should give it a try?
Stuck And Bother
I’m currently working on a project with a real, hard deadline. My team has to demonstrate a working, multi-million dollar radar in the near future to a potential deep-pocketed customer. As you can see below, the tower is up and the antenna is majestically perched on its pedestal. However, it ain’t spinning yet. Nor is it radiating energy, detecting signal returns, or extracting/estimating target information (range, speed, angle, size) buried in a mess of clutter and noise. But of course, we’re integrating the hardware and software and progressing toward the goal.
Lest you think otherwise, I’m no Ed Snowden and those pics aren’t classified. If you’re a radar nerd, you can even get this particular radar emblazoned on a god-awful t-shirt (like I did) from zazzle.com:
OK, enough of this bulldozarian levity. Let’s get serious again – oooh!
As a hard deadline approaches on a project, a perplexing question always comes to my mind:
How much time should I spend helping others who get “stuck“, versus getting the code I am responsible for writing done in time for the demo? And conversely, when I get stuck, how often should I “bother” someone who’s trying to get her own work done on time?
Of course, if you’re doing “agile“, situations like this never happen. In fact, I haven’t ever seen or heard a single agile big-wig address this thorny social issue. But reality being what it is, situations like this do indeed happen. I speculate that they happen more often than not – regardless of which methodology, practices, or tools you’re using. In fact, “agile” has the potential to amplify the dilemma by triggering the issue to surface on a per sprint basis.
Save for the psychopaths among us, we all want to be altruistic simply because it’s the culturally right thing to do. But each one of us, although we’re sometimes loathe to admit it, has been endowed by mother nature with “the selfish gene“. We want to serve ourselves and our families first. In addition, the situation is exacerbated by the fact that the vast majority of organizations unthinkingly have dumb-ass recognition and reward systems in place that celebrate individual performance over team performance – all the while assuming that the latter is a natural consequence of the former. Life can be a be-otch, no?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 