Archive
The Right Tool For The Job
The figure below depicts a scenario where two targets are just about to penetrate the air space covered by a surveillance radar.
The next sequence of snapshots illustrates the targets entering, traversing, and exiting the coverage volume.
Assume that the surveillance volume is represented in software as a dynamically changing, in-memory database of target objects. On system startup, the database is initialized as empty. During operation, targets are inserted, updated, and deleted in response to changes that occur in the “real” world.
The figure below models each target’s behavior as a state transition diagram (STD). The point to note is that a target in a radar application is stateful and mutable. Regardless of what functional language purists say about statefulness and mutability being evil, they occur naturally in the radar application domain.
Note that the STD also indicates that the application domain requires garbage collection (GC) in the form of deallocation of target memory when a detection hasn’t been received within X seconds of the target’s prior update.
Since the system must operate in real-time to be useful, we’d prefer that the target memory be deleted as soon as the real target it represents exits the surveillance volume. We’d prefer the GC to be under the direct, local, control of the programmer and not according to the whims of an underlying, centralized, virtual machine whose GC kicks it whenever it feels like it.
With these domain-specific attributes in mind, C++ seems like the best programming language fit for real-time radar domain applications. The right tool for the job, no? If you disagree, please state your case.
Two Opposing Ideas
If you didn’t already know it, I’m a fan of the C++ programming language. Of course, not everybody feels the same way. There are many smart people who are among the “haters“.
C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. – Linus Torvalds
When I read anti-C++ tirades like Linus Torvalds’ emotionally charged attack, it always stings a little at first. But then I eventually step back from the “emotional-me” and remember (thanks to the teachings of Byron Katie and Eckart Tolle) that the world will never be the way I “demand!” it to be. The length of time it takes me to disengage from abstract thought-storms like these and return to earth is proportional to how deeply I’m attached to one side of the debate stomping around in my head.
“The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function.” – F. Scott Fitzgerald
Java creator James Gosling, Haskell‘s Bartosz Milewski, and Go creator Rob Pike are three of the more prominent people in the anti-C++ camp. As expected, they have agendas to promote: advocating their own favorite programming languages at the expense of C++.
- Milewski’s rant: “Edward C++Hands“
- Pike’s rant: “Less Is Exponentially More“
- Gosling’s rant: “The Java Language Environment“
Ironically, these rants by smart and well known people can be construed as tributes to C++. That’s probably why this is one of my favorite Bjarne Stroustrup quotes:
There are just two kinds of languages: the ones everybody complains about and the ones nobody use.
They’ve Finally Done It, They Are In Control!
Oh ratz! BD00 wishes he concocted this brilliant “Planet Of The Apes” parody T-shirt:
But alas, BD00 didn’t create the masterpiece. The Random Manager team did. Damn it! Here’s the BD00 rip off version:
Ill Equipped And Discounted
In a 2012 slideshare deck that built a case for a hostile takeover of Blackberry maker RIM (Research In Motion), venture capitalist Robin Chan hoisted this foil of the smugly smiling C-level dudes running the show at DIM (Disaster In Motion):
To add insult to injury, Mr. Chan writes:
D’oh! C-Level infallibles don’t like being characterized as “ill equipped” and “discounted“. However, fear not for the dissed DIMwit royalty. Since DIM recently announced plans to frantically find a buyer for their struggling business, these execs will make out just fine. The golden parachutes will be doled out, they’ll hop on a plane to their next destination, glide right into the C-suites at their next gigs, and have their smiling picture taken for the next annual report. Who sez performance matters?
Tradition and Progress
Continuing on with a series of posts fueled by the inspirational content in Scott Berkun’s newly minted “The Year Without Pants“, let’s explore the relationship between tradition and progress:
There is nothing wrong with tradition until you want progress: progress demands change, and change demands a reevaluation of what the traditions are for and how they are practiced…. The responsibility of people in power is to continually eliminate useless traditions and introduce valuable ones. An organization where nothing ever changes is not a workplace but a living museum. – Scott Berkun
In poorly led institutions, as the number of management (“management” is simply a euphemism for “control“) layers increases, new “special interest” traditions are continuously introduced into the environment whilst old and useless rituals are rarely eliminated. Policies, directives, processes, procedures, taxes, fees, laws – pick your poison. The pile of behavior constraining rules just gets bigger and bigger, suffocating all intrinsic motivation and instilling learned helplessness. Damn, that Kafka dude got it right. So did Ackoff:
It is easier to start something new than it is to stop something old – Russell Ackoff.
The Confusion Of Roles
Scott Berkun’s books have always been lucrative gold mines for bloggers wanting to explore novel ideas and insights. His latest release, “The Year Without Pants“, is no different.
In TYWP, Scott discloses a major cultural malady that plagues corpo America: “The Confusion Of Roles“.
One major mistake Schneider (Automattic Inc’s CEO) had seen was how companies confused supporting roles, like legal, human resources, and information technology, with product creation roles like design and development. Product creators are the true talent of any corporation, especially one claiming to bet on innovation. The other roles don’t create products and should be there to serve those who do. A classic betrayal of this idea is when the IT department dictates to creatives what equipment they can use. If one group has to be inefficient, it should be the support group, not the creatives. If the supporting roles, including management, dominate, the quality of products can only suffer. – Scott Berkun
The “Confusion Of Roles” is simply not a problem at Automattic Inc. That’s because there are no legal, human resources, finance, quality assurance, or information technology silos within the flat-as-a-pancake company.
Well, that’s all fine and dandy for a cozy, small company like Automattic. But there is no cure for the “role confusion” disease in big borgs like yours, right? Bzzzzt!
HCLT CEO Vineet Nayar wrote about the exact same productivity and morale killer in his shockingly titled “Employees First, Customers Second” book. Taking the bull by the horns, Vineet corrected the “confusion of roles” epidemic at his 30,000 person Leviathon by inverting the pyramid and instituting a transparent system of reverse accountability called the Smart Service Desk (SSD) .
The SSD is where front line employees can submit problem tickets against the (so-called) support functions. Each ticket has a deadline date and the submitter is the ultimate judge of results – not some self-important manager. Shortly after its introduction, the SSD was receiving tickets at a rate of 30,000 per month – one per employee. D’oh!
Why, you may be asking, aren’t there more “unconfusion-of-roles” change efforts taking place in the land of a million pointy hierarchies? It’s because the pinnacle dwellers who rule the roost don’t see it as a problem at all. It’s the way it is because it’s always been that way and, more importantly, it’s the way it’s supposed to be.
The Drooping Progress Syndrome
When a new product development project kicks off, nobody knows squat and there’s a lot of fumbling going on before real progress starts to accrue. As the hardware and software environment is stitched into place and initial requirements/designs get fleshed out, productivity slowly but surely rises. At some point, productivity (“velocity” in agile-ese) hits a maximum and then flattens into a zero slope, team-specific, cadence for the duration. Thus, one could be led to believe that a generic team productivity/progress curve would look something like this:
In “The Year Without Pants“, Scott Berkun destroys this illusion by articulating an astute, experiential, observation:
This means that at the end of any project, you’re left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them). It should never be a surprise that progress seems to slow as the finish line approaches, even if everyone is working just as hard as they were before. – Scott Berkun
Scott may have forgotten one class of thing that BD00 has experienced over his long and un-illustrious career – things that need to get done but aren’t even in the work backlog when deployment time rolls in. You know, those tasks that suddenly “pop up” out of nowhere (BD00 inappropriately calls them “WTF!” tasks).
Nevertheless, a more realistic productivity curve most likely looks like this:
If you’re continuously flummoxed by delayed deployments, then you may have just discovered why.
Related articles
- The Year Without Pants: An interview with author Scott Berkun (oldienewbies.wordpress.com)
- Scott Berkun Shares Advice for Writers Working Remotely (mediabistro.com)
- A Book in 5 Minutes: “The Year without Pants: WordPress.com and the Future of Work” (tech.co)
A Concrete Agile Practices List
Finally, I found out what someone actually thinks “agile practices” are. In “What are the Most Important and Adoption-Ready Agile Practices?”, Shane-Hastie presents his list:
Kudos to Shane for putting his list out there.
Ya gotta love all the “explicit definition of done” entries (“Aren’t you freakin’ done yet?“). And WTF is “Up front architecture” doing on the list? Isn’t that a no-no in agile-land? Shouldn’t it be “emergent architecture“? And no kanban board entry? What about burn down charts?
Alas, I can’t bulldozify Shane’s list too much. After all, I haven’t exposed my own agile practices list for scrutiny. If I get the itch, maybe I’ll do so. What’s on your list?
Pragmatically Feasible?
From the MISRA web site:
The Motor Industry Software Reliability Association (MISRA), is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems.
While browsing through the MISRA C++:2008 standard, I came across this not-unexpected requirement:
I don’t know enough about the standard to know if it’s true, but I interpret this requirement as banning not only the use of “new/delete“, but also as banning the use of the dynamically managed STL container abstractions (vectors, lists, sets, maps, queues) and, hence, the many standard library algorithms that operate on them. I wonder what the MISRA Java specification, if there is one, says about dynamic memory allocation.
If my interpretation of 18-4-1 is correct, then the requirement can severely jack up the cost, schedule, and technical risks of any software component that is required to be compliant with the specification. For non-trivial applications requiring more than low-level, statically allocated arrays…..
Complexity is pushed out of the language and into the application code. The semantics of language features are far better specified than the typical application code. – Bjarne Stroustrup & Kevin Carroll
Because of the safety-critical nature of embedded automotive software, I can understand the reasoning behind the no-dynamic-memory-allocation requirement. But is it pragmatically feasible in today’s world; especially since software components keep getting larger and commensurately more complex over time? In other words, is it one of those requirements that doesn’t scale? Is it too Draconian?
For those C++ programmers who work in the automotive industry and happen to stumble upon this blog (which will probably be none), what has been your experience with this MISRA requirement and some of the other similarly unsettling requirements in the specification? Are “waivers” often asked for and granted? Is it an unspoken truth that people/companies pay public lip service to the requirement but privately don’t comply?
The Biggest Cheerleader
Herb Sutter is by far the biggest cheerleader for the C++ programming language – even more so than the language’s soft spoken creator, Bjarne Stroustrup. Herb speaks with such enthusiasm and optimism that it’s infectious.
In his talk at the recently concluded GoingNative2013 C++ conference, Herb presented this slide to convey the structure of the ISO C++ Working Group 21 (WG21):
On the left, we have the language core and language evolution working groups. On the right, we have the standard library working group.
But wait! That was the organizational structure as of 18 months ago. As of now, we have this decomposition:
As you can see, there’s a lot of volunteer effort being applied to the evolution of the language – especially in the domain of libraries. In fact, most of the core language features on the left side exist to support the development of the upcoming libraries on the right.
In addition to the forthcoming minor 2014 release of C++, which adds a handful of new features and fixes some bugs/omissions from C++11, the next major release is slated for 2017. Of course, we won’t get all of the features and libraries enumerated on the slide, but the future looks bright for C++.
The biggest challenge for Herb et al will be to ensure the conceptual integrity of the language as a whole remains intact in spite of the ambitious growth plan. The faster the growth, the higher the chance of the wheels falling off the bus.
“The entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down.” – Fred Brooks
“Who advocates … for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks
I’m not a fan of committees in general, but in this specific case I’m confident that Herb, Bjarne, and their fellow WG21 friends can pull it off. I think they did a great job on C++11 and I think they’ll perform just as admirably in hatching future C++ releases.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 