I’m currently designing/writing the software component of a new air surveillance radar data processor that interfaces the radar to an existing, legacy combat control system. In order to test the software, I have to interact with the combat system’s GUI to issue radar commands and ensure that detected targets are received and displayed properly on the combat system display.
As the figure above shows, the acronym “SS2000” appears prominently on the GUI display. When I saw it for the first time, a sense of deja-vu came over me, but I couldn’t figure out why. After a few days of testing, I experienced an AHA! epiphany. Out of the blue, I suddenly remembered where I saw “SS2000” before. Ding!
Ya see, back in the early 2000′s, I read a Software Engineering Institute (SEI) case study on the concept of “software product lines“. It featured a Swedish company called “Celsius Tech“. The report meticulously described how Celsius Tech painfully transformed itself in the 90′s from an expensive developer of one-off naval combat systems into an efficient, low cost, high quality, producer of systems. Instead of starting from scratch on each new system development, Celsius Tech “instantiated” each new system from an in-place, reusable set of product line assets (code and requirements/design/test documentation) that they diligently built upfront.
I was so enamored with Celsius Tech’s technical and financial success with the concept of software product lines that I concocted an executive summary of the report and aggressively pitched it internally to everyone and anybody who would listen. But alas, I utterly failed to jumpstart an internal effort to transform my employer at the time, Sensis Corp., into a software product line enterprise.
The name of Celsius Tech’s software product line infrastructure was…… SS2000 = Ship System 2000! But wait, the story gets eerily better. Celsius Tech was subsequently purchased by Swedish defense company Saab AB (yes, they used to make cars but they sold off that business a long time ago) – the same company that bought my employer, Sensis Corp., in 2011. As a result of the buyout, I currently work for Saab Sensor Systems. Quite the coincidence, no?
When a control system is humming along, the gap between the desired and current states is so small that the frequency of command issuance by the Decision Maker component is essentially zero; all is well and goal attainment is on track. However, with the universe being as messy as it is, unseen and unpredictable “disturbances” can, and do, enter the system at any point of access to the structure.
If the sensors and/or actuators can’t filter out the disturbances or are malfunctioning themselves, then true control of the production system may be lost. Perceptions and commands get distorted and the distance between goal attainment and “reality” will be perceived as shorter or longer than they are. D’oh! I hate when that happens.
W00t! The pre-release version of Scott Meyers’ “Effective Modern C++” book is currently available to SafariBooksOnline subscribers:
In case you were wondering, here is the list of items Scott covers:
I’m currently on item number 11. What item are you on? :P
In case you were wondering what the hell the title of this post has to do with the content of it, here’s the missing piece of illogic:
Check out these three financial portfolio performance graphs from Mr. Nassim Taleb:
A fragile portfolio is one which is prone to getting decimated by a rare, unpredictable, event (a.k.a. a Black Swan). A robust portfolio is one which is relatively immune to the effects of a devastating Black Swan. An antifragile portfolio is one which experiences spectacular gains from a Black Swan.
Mr. Taleb asserts that the world’s financial system has been (since the 80′s when we first started bailing out banks), and still is, fragile. As long as bankers know that we, the taxpaying public, will continue to shoulder the cost when they blowup because they are too big too fail, they will continue to exhibit incompetent, reckless, risky behavior backed by bogus PhD calculations. They get their perennial bonuses before each big bust for “doing well“, but aren’t forced to give them back when they lose more money in an instant from a Black Swan than all the profits they’ve ever made previously in the history of banking. It’s a no-brainer with all upside and no downside. What a life… if you don’t have a conscience.
So, how do you construct a anti-fragile portfolio? According to Mr. Taleb, you allocate 80% of your portfolio to “cash” and 20% to wildly speculative investments. It’s called the barbell strategy – weighted investments at both ends of the risk spectrum and nothing in the middle. In the worst case, you’ll lose the full 20%, but the sky is the limit if you’re right with your speculative investment choices. The challenges are:
- To muster up the nerve to actually go against what the mindless “portfolio theory” trained herd says and reallocate your currently fragile portfolio,
- Figure out exactly what Nassim means by “cash” (no, it’s not a savings account at Citibust or Bank Of Nightmerica),
- Decide on which speculative financial instruments to invest in (gold/metals? commodities? real estate? “other”?) .
BD00 knows what these challenges are because, as an unsophisticated investor, he’s struggling to conquer them himself. WTF!
Alfie Kohn‘s “Punished By Rewards” is the classic go-to book on why/how rewards destroy intrinsic motivation and fuel intra-group competition and politicking. In “Want To Stay Productive? Turn Down The Next Award You Win“, Drake Baer gives yet another example of the motivation-busting effect of reward systems.
Do medals, advanced degrees, fancy titles, and huge bonuses tend to fatten the heads of their receivers (and their givers) to the point of lazyness? Do they create an attitude of entitlement in the minds of their receivers (and their givers)?
W00t! I’ve arrived! No need to do real work anymore. I’ve been placed above the herd by those who have the “authority” to do so – and who, by extension, are two levels above the herd.
I can’t rave enough about how great a safaribooksonline.com subscription is for writing code. Take a look at this screenshot:
As you can hopefully make out, I have five Firefox tabs open to the following C++11 programming books:
- The C++ Programming Language, 4th Edition – Bjarne Stroustrup
- The C++ Standard Library: A Tutorial and Reference (2nd Edition) – Nicolai M. Josuttis
- C++ Primer Plus (6th Edition) – Stephen Prata
- C++ Primer (5th Edition) – Stanley B. Lippman, Josée Lajoie, Barbara E. Moo
- C++ Concurrency in Action: Practical Multithreading – Anthony Williams
A subscription is a bit pricey, but if you can afford it, I highly recommend buying one. You’ll not only write better code faster, you’ll amplify your learning experience by an order of magnitude from having the capability to effortlessly switch between multiple, independent sources of information on the same topic. W00t!
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?
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?