Archive
Different Perceptions
In the spirit of reducing costs through the holy grail of “reuse“, this post leverages the (so-called) work done in the recent “One Of Four” post….
In DYSCOs and CLORGs, this is everybody’s perception:
Man, I wish I could cure myself of the addiction to use grumpies in my e-drawings. The practice is unprofessional and childish, but I deploy the putrid piles for the following purposes: 1) to ratchet up the impact, 2) as a differentiating “branding” gimmick, and 3) to coverup the lack of substance in the accompanying words. The acerbic words and sophomoric readme.txt acronyms may already do the trick though, no?
What do you think, dear reader? Should BD00 dispense with all the crap? Do you think BD00 is capable of, and willing to, step into the alien world of respectable discourse?
Ideologues
This may sound hypocritical to some, but I find it frustratingly difficult to deal with ideologues. An ideologue is a closed-minded, binary, absolutist when it comes to “beliefs” that he/she is passionate about.
Experts don’t think, they know (just like BD00).
As soon as you start to question assertions from an ideologue or suggest an alternative idea/concept/belief, in the blink of an eye you automatically become an enemy to be annihilated. The rhetoric starts ratcheting up and personal attacks may start spewing forth. Unless you’re the Buddha, it’s incredibly easy to get sucked into the vortex and start playing the ISTY game with an ideologue. On the up side, if you deal with ideologues often, with a little self-awareness, you can get better and better at handling interactions with them more gracefully.
Being a passionate person myself on topics that are near and dear to me, I can definitely empathize with ideologues. I “believe” that if you’re not passionate about something, then you’re living an incredibly boring and unfulfilled life. But hey… it’s just a BD00 “belief“.
I believe that there is such a thing as objective truth, but a lot of people have an objective truth that differs from mine. – Cynthia Tucker
TDD Overhype
There is much to like about unit-level testing and its extreme cousin, Test Driven Design (TDD). However, like with any tool/technique/methodology, beware of overhyping by snake oil salesman.
Cédric Beust is the author of the book, “Next Generation Java Testing“. He is also the founder and lead developer of TestNG, the most widely used Java testing framework outside of JUnit. In a Dr. Dobb’s guest post titled “Breaking Away From The Unit Test Group Think”, I found it refreshing that a renowned unit testing expert, Mr. Beust, wrote about the down side of the current obsession with unit testing:
- Unit tests are a luxury. Sometimes, you can afford a luxury; and sometimes, you should just wait for a better time and focus on something more essential — such as writing a functional test.
- There are two specific excesses regarding code coverage: focusing on an arbitrary percentage and adding useless tests.
- TDD code also tends to focus on the very small picture: relentlessly testing individual methods instead of thinking in terms of classes and how they interact with each other. This goal is further crippled by another precept called YAGNI, (You Aren’t Going to Need It), which suggests not preparing code for features that you don’t immediately need.
- Obsessing over numbers in the absence of context leads developers to write tests for trivial pieces of their code in order to increase this percentage with very little benefit to the end user (for example, testing getters).
Being a designer and developer of real-time, multi-threaded code that runs 24 X 7, I’ve found that unit testing is not nearly as cost effective as functional testing. As soon as I can, I get a skeletal instance of the (non-client-server) system that I’m writing up and running and I pump deterministic, canned data streams through the system from end-to-end to find out how the beast is behaving. As I add functionality to the code base, I rerun the data streams through the system again and again and I:
- try to verify that the new functionality inserted into the threading structure works as expected
- try to ensure that threads don’t die,
- try to verify that there are no deadlocks or data races in the quagmire
If someone can show me how unit testing helps with these issues, I’m all ears. No blow hard pontificating, please.
One Of Four
Basement Garden
After concocting yesterday’s irreverent post, the universe whispered in my ear:
Put a visual to the saying: DYSCOs often treat their “associates” like mushrooms: Down in the basement and well fed with chit.
Since I don’t want to piss the universe off, here t’is:
Toxic Fungus
Unless due diligence is performed on the part of an org’s leadership junta/cabal/politburo, fragmentation of responsibility and unessential specialization can easily creep into “the system” – triggering a bloat in costs and increased operational rigidity. Like a toxic fungus, not only is it tough to prevent, it’s tough to eradicate. D’oh! I hate when that happens.
Admittance Of Imperfection
One of the traits I admire most about Bjarne Stroustrup is that he’s not afraid to look “imperfect” and point out C++’s weaknesses in certain application contexts. In his “Technical Report On C++ Performance“, Mr. Stroustrup helpfully cautions real time programmers to think about the risks of using the unpredictable/undeterministic features of the language:
Of course, C++ antagonists are quick to jump right on his back when Bjarne does admit to C++’s imperfections in specific contexts: “see, I told you C++ sux!“.
Here’s a challenge for programmers who read this inane blog. Can you please direct me to similar “warning” clauses written by other language designers? I’m sure there are many out there. I just haven’t stumbled across one yet.
Persistent Discomfort
As part of the infrastructure of the distributed, multi-process, multi-threaded system that my team is developing, a parameterized, mutex protected, inter-thread message queue class has been written and dropped into a general purpose library. To unburden application component developers from having to do it, the library-based queue class manages a reusable pool of message buffers that functionally “flow” from one thread to the next.
On the “push” side of the queue, usage is as follows:
- Thread acquires a handle to the next empty Message buffer
- Thread fills Message buffer
- Thread returns handle to the queue (push)
On the “pop” side of the queue, usage is as follows:
- Thread acquires a handle to the next full Message buffer (pop)
- Thread processes the Message content
- Thread returns handle to the queue
So far, so good, right? I thought so too – at the beginning of the project. But as I’ve moved forward during the development of my application component, I’ve been experiencing a growing and persistent discomfort. D’oh!
Using the figure below, I’m gonna share the cause of my “inner thread” discomfort with you.
In order to functionally process an input message and propagate it forward, the inner thread must do the following work:
- Acquire a handle to the next input Message buffer from queue 1 (pop)
- Acquire a handle to the next empty output Message buffer from queue 2
- Utilize the content of the Message from queue 1 to compute/fill in the Message to queue 2
- Return the handle of the input message to queue 1
- Return the handle of the output message to queue 2 (push)
For small messages and/or when the messages are of different types, I don’t see much wrong with this inter-thread message passing approach. However, when the messages are big and of the same type, my discomfort surfaces. In this case (as we shall see), the “utilize” bullet amounts to an unnecessary copy. The more “inner” threads there are in the pipeline, the more performance degradation there is from unnecessary copies.
So, how can the copies be eliminated and system performance increased? One way, as the figure below shows, is to move message buffer management responsibility out of the local queue class and into a global, shared message pool class.
In this memory-less queue design, the two pipeline end point threads explicitly assume the responsibility of acquiring and releasing the Message buffer handles from the mutex protected, shared message pool. The first thread “acquires” and the last thread “releases” message buffer handles. Each inner thread, i, in the pipeline performs the following work:
- Pop the handle to the next input Message buffer from queue i-1
- Process the message
- Push the Message buffer handle to queue i
The key to avoiding unessential inner thread copies is that the messages must be intentionally designed to be of the same type.
As soon as I get some schedule breathing room (which may be never), I’m gonna refactor my application infrastructure design and rewrite the code to implement the memoryless queue + global message pool approach. That is, unless someone points out a fatal flaw in my reasoning and/or presents a superior inter-thread message communication pattern.
Writer’s Block!
After aimlessly doodling with my ad-hoc clipart pallet for awhile , I concocted this monstrosity:
Surprisingly, I drew a blank when I tried to conjure up a delusional story to bind to the drawing. This must be what writer’s block is. D’oh!
Can you please fill in the void for me? Think of it as a creative writing assignment.
Is It Safe?
Assume that we place a large, socio-technical system designed to perform some safety-critical mission into operation. During the performance of its mission, the system’s behavior at any point in time (which emerges from the interactions between its people and machines), can be partitioned into 2 zones: safe and unsafe.
Since the second law of dynamics, like all natural laws, is impersonal and unapologetic, the system’s behavior will eventually drift into the unsafe system behavior zone over time. Combine the effects of the second law with poor stewardship on behalf of the system’s owner(s)/designer(s), and the frequency of trips into scary-land will increase.
Just because the system’s behavior veers off into the unsafe behavior zone doesn’t guarantee that an “unacceptable” accident will occur. If mechanisms to detect and correct unsafe behaviors are baked into the system design at the outset, the risk of an accident occurring can be lowered substantially.
Alas, “safety“, like all the other important, non-functional attributes of a system, is often neglected during system design. It’s unglamorous, it costs money, it adds design/development/test time to the sacred schedule. and the people who “do safety” are under-respected. The irony here is that after-the-accident, bolt-on, safety detection and control kludges cost more and are less trustworthy than doing it right in the first place.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 