Archive
A Real Renaissance
For quite some time now, I’ve been hearing that C++ has been undergoing a resurgence of interest; a renaissance. However, until recently, I couldn’t tell if the claim was real, or just some hype coming out of the C++ community to fruitlessly combat the rise of a plethora of new languages.
Well, I’m convinced that the renaissance is legit. The slides below, pilfered from Herb Sutter‘s “The Future Of C++” talk at Microsoft Build 2012, introduced the formation of a new C++ trade group, the “Standard C++ Foundation“.
Note that there are some big guns with deep pockets backing the foundation along with a cadre of brilliant and dedicated directors at the helm.
It’s a good time to be a C++ programmer, so join the renaissance and start learning the new features and libraries offered up in C++11. Of course, if your technical management is not forward looking and it’s tight with training dollars, you’ll have to do it on your own time, covertly, behind the scenes. But it will not only be fun, it will enhance your marketability.
One Hit, One Miss
In “So Far from Home: Lost and Found in Our Brave New World“, Margaret J. Wheatley hits the mark with BD00:
The interactive nature of the Net distinguishes it from all earlier technologies; from the start, it was based on public interactions, not on private use such as with books or recordings. It fed on two powerful human needs— to be visible and to connect— at a time when we were already feeling lonely and invisible. Our insatiable appetites for self-creation and self-expression have transformed us into twenty-first-century hunter-gatherers. We’ve become addicted to what else we might find, where the next click might lead us, so we incessantly keep hunting.
Meg also misses the mark with:
…we’ve abandoned the thinking skills we humans developed over many centuries of evolution: abstract thinking, nuanced language, envisioning, moral reasoning, the scientific method.
Note that the hit and miss only apply to BD00; according to BD00. How do they apply to you; according to you?
King Of The Hill
Scrum is an agile approach to software development, but it’s not the only agile approach. However, because of its runaway success of adoption compared to other agile approaches (e.g. XP, DSDM, Crystal, FDD), a lot of the pro and con material I read online seems to assume that Agile IS Scrum.
This nitpicking aside, until recently, I wondered why Scrum catapulted to the top of the agile heap over the other worthy agile candidates. Somewhere online, someone answered the question with something like:
“Scrum is king of the hill right now because it’s closer to being a management process than a geeky, code-centric set of practices. Thus, since enlightened executives can pseudo-understand it, they’re more likely to approve of its use over traditional prescriptive processes that only provide an illusion of control and a false sense of security.”
I think that whoever said that is correct. Why do you think Scrum is currently the king of the hill?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Scrum And Non-Scrum Interfaces (bulldozer00.com)
The C++ Product Roadmap
Fresh from the ISO C++ chairman himself, Herb Sutter, I present you with the C++ product roadmap:
If all goes according to plan, a minor release of the ISO standard will be hatched in 2014. By minor, Herb means that it will be mostly bug fixes to C++11, plus a filesystem library based on Boost.org‘s brilliant work. The networking library, which is big and being developed by a large group of smart people, will be hatched incrementally in a series of Technical Specifications (TS).
The main point that Herb stressed when he hoisted the slide was that “the past is not a good predictor of the future“. If all goes according to plan, the time between major releases of the standard will have been cut from 13 years to 6.
Ignored, Denied, Or Pushed Aside
Fresh from Margaret Wheatley‘s “So Far from Home: Lost and Found in Our Brave New World“, I present you with these four vexing questions:
If you answered “yes” to any of these questions and your expectations were met, then you’re incredibly lucky because:
They’re based on an assumption of rational human behavior— that leaders are interested in what works— and that has not proven true. Time and again, innovators and their highly successful projects are ignored, denied or pushed aside, even in the best of times. In this dark era, this is even more true. – Margaret Wheatley
Not that I’m an innovator, but these questions hit me hard because it took decades of disappointment and bewilderment for me to realize that Ms. Wheatley is right. But you know what? Once I became truly aware that “it is the way it is“, I felt liberated. Now I do the work for the work itself. An intimate, joyful communication between the creator and the created.
Quantum Chaotic Complexity
How many institutions are still being managed in accordance with the knowledge learned from 17th century physics? These days, its networks and relationships, not billiard balls and force.
Blown, Busted, And Riddled
The CMMI-DEV model for software development contains 20+ Key Process Areas (KPA) that are required to be addressed by an org in order to achieve a respectable level of compliance. With such complexity, one could think that L3+ orgs would sponsor periodic process refresher courses for their DICforces in order to minimize social friction between process enforcers and enforcees and reduce time-sucking rework resulting from innocent process execution errors made by the enforcees.
BD00 postulates that many CMMI L3+ orgs don’t hold periodic, rolling process refreshers for their cellar dwellers. The worst of the herd periodically retrains its technical management and process groups (enforcers) , but not its product development teams (enforcees). These (either clueless or innocently ignorant) orgs deserve what they get. Not only do they get blown budgets, busted schedules, and bug-riddled products, but they ratchet up the “us vs. them” social friction between the uninformed hands-on product dweebs and the informed PWCE elites.
So Professional That It’s Unprofessional
Mike Williams is one of the big three Erlang creators (along with Joe Armstrong and Robert Virding) and the developer of the first Erlang Virtual Machine. Since then, he’s “moved up” and has been working as a software engineering manager for 20+ years. In his InfoQ talk titled “The Ideal Programmer – Why They Don’t Exist and How to Manage Without Them?“, Mike presents this hilarious slide:
It’s hilarious because, if you browse web sites like LinkedIn.com and Monster.com, you’ll find tons of similar, impossible-to-satisfy job descriptions. Everybody, especially the job description writer, knows that exhaustive “requirements” lists like these are a crock of BS. This practice is so professional that it’s unprofessional. So, why does it persist?
Leaders, Followers, Standers
Everybody knows what leaders and followers are, but what about “standers“? A stander is not a slacker. It’s a capable person who is content to stay within his/her comfort zone doing the same thing over and over again.
BD00 thinks that all people are capable and they innately want to “move” forward either as a leader or a follower. It’s a social system’s culture that molds “standers” out of capable people.
In cultures where mistakes of commission are penalized and mistakes of omission go undetected and unacknowledged, the optimum strategy, courtesy of Russell Ackoff, is simply to do as little as needed to elude ex-communication. It’s stagnation city with a burgeoning population of standers; sad for the people and sad for the org.
The Undiscussable Issues Of Code Reviews
Everyone and their brother, including BD00, thinks source code inspections are a best practice for detecting and eliminating defects before they burrow into your code to wreak havoc during expensive, downstream debugging debacles. There are reams of study data to support the efficiency of code reviews (relative to testing) in the battle of the bug. But, the world being as messy as it is, there’s a fly in the ointment. That fly is the cost required to, and this is important, “effectively” execute code reviews:
“And yet, at somewhere around 100 lines of code inspected per hour, it takes an investment of many hours to inspect even the smallest piece of software, say a couple of thousand of lines of code.” – Facts And Fallacies Of SW Engineering, Robert Glass, P106
“There’s a sweet spot around 150 lines per hour that detects most of the bugs you’re going to find.” – The Art Of Designing Embedded Systems, Jack Gannsle, P21
Given these metrics, let’s concoct a concrete example so we can further investigate the cost issue :
Assuming the simple math is correct, the project manager in this example should “explicitly” allocate $200K and 4 calendar months of effort somewhere in his/her micro-managed Microsoft Project plan for our 100K line program, no?
The question is, when was the last time you saw a project plan that transparently and explicitly enumerated the time and cost for performing those code reviews mandated by your CMMI L3+ compliant process? If you haven’t seen such a plan, find out what kind of blowback you get from asking to have the resources required for “effective” code reviews embedded in your current or next prescriptive project plan. For even more drama, ask your QA group if there are any metrics (bugs found/review-hour, bug densities) that indicate how effective your code reviews are.
Since we’re having fun here, let’s go a little deeper into this undiscussable underworld by examining these two assumptions from our fabricated example:
- The reviewers are qualified and readily available: they understand the programming language(s) the code is written in; they have memorized the 200 page home-grown coding standards manual(s); they understand and have memorized the functional requirements the code is supposed to implement.
- The reviews are synchronized; the reviewers all start and end the code review at the same time.
Are these assumptions realistic? If not, then how do the budget and schedule numbers get affected?
Finally, in an iterative and incremental development process, when should code reviews take place? Piece-meal and disruptively after checking in each increment’s unit-tested code? In one big, formal she-bang after all the unit tests have passed?
How do you do code reviews, and how effective are they?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 