Archive
It’s Hammer Time!
The title of this post should have been “It’s Hammurabi Time!”, but it’s not as catchy as “It’s Hammer Time!“.
King Hammurabi lived over 2000 years ago and he was perhaps the first staunch “eye for an eye” dude:
Too bad we don’t have a slightly less Draconian, modern day version of Hammurabi’s creed that applies to Wall St. bankers (who take bailout money), crooked politicians (who get re-elected), and self-serving executives (who get unconditional exit bonuses). Many of these dudes do massive harm to their constituents without having to account for their actions.
Actually, we do have laws that attempt to ensure justice is served, but we also have expensive lawyers who ensure that the rich and powerful can play the game without any skin in it.
How do I get to become a member of the “All Upside and No Downside” club?
Designed To Be Fooled
Bravery, courage, self-confrontation, acceptance-of-limitations? WTF! BD00 doesn’t possess any of those attributes. But when the ink dries on this blog post, he’ll go back to foolishly thinking he does (what about you?). Mr. Taleb is right – mother nature is a tricky be-otch.
Shortcutting The Shortcut
BD00 has heard from several sources that it takes about 10 years for a winning technology to make it into the mainstream. After starting off with a slow uptake due to fear and uncertainty, the floodgates open up and everybody starts leveraging the technology to make more money and greater products.
This 10 year rule of thumb surely applies to the “agile” movement, which recently celebrated its 10th anniversary. But as the new book below shows, the frenzy can get laughably outta control.
Not to rag too much on Mr. Goldstein, but sheesh. As if Scrum is not “fast” enough already? Now we’re patronizingly told that we need “intelligent” shortcuts to make it even faster. Plus, we idiots need to learn what these shortcuts are and how to apply them in a “step-by-step” fashion from a credentialed sage-on-a-stage. Hey, we must be idjets cuz, despite the beautiful simplicity of Scrum, Mr. Goldstein implies that we keep screwing up its execution.
As usual, BD00 hasn’t read the ground breaking new book. And he has no plan to read it. And he has no plan to stop writing about topics he hasn’t researched “deeply“. Thus, keep reminding yourself that:
Possibly The Worst Ever
“It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth” – W. E. Deming
“You can only measure 3% of what matters.” – W. E. Deming
Even though he’s more metrics-obsessed than I’d prefer, in general I’ve been a fan of Capers Jones‘s contributions to the software development industry. In his interesting InfoQ article, “Evaluating Agile and Scrum with Other Software Methodologies“, Capers defines, as one of his methodology candidates, possibly the worst software methodology ever conceived:
CMMI 1 with waterfall: The Capability Maturity Model Integrated™ (CMMI) of the Software Engineering Institute is a well-known method for evaluating the sophistication of software development. CMMI 1 is the bottom initial level of the 5 CMMI levels and implies fairly chaotic development. The term “waterfall” refers to traditional software practices of sequential development starting with requirements and not doing the next step until the current step is finished. – Capers Jones
I shouldn’t laugh, but LOL! In the “beginning“, virtually all software projects were managed in accordance with the “Chaos + Waterfall” methodology. Even with all the progress to date, I’d speculate that many projects unwittingly still adhere to it. Gee, I wonder how many of these clunkers are lurching forward under the guise of being promoted as “agile“.
Moving on to the scholarly guts of Mr. Jones’ article, he compares 10 of his personally defined methodologies in terms of several of his personally defined speed, quality, and economic metrics. He also uses his personal, proprietary models/equations/assumptions to calculate apparently objective results for evaluation by executive decision-makers.
I’m not going to discuss or debate the results of Capers’ comparisons because that’s not why I wrote this post. I wrote this post because personally, I don’t think personal and objective mix well together in efforts like these. There’s nothing wrong with smart people generating impressive numeric results that appear objective but are based on hidden/unknown personal assumptions and mental models. However, be leery of any and every numeric result that any expert presents to you.
To delve more deeply into the “expert delusion“, try reading “Proofiness: How You’re Being Fooled by the Numbers” or any of Nassim Taleb‘s books.
The Importance Of Locality
Since I love the programming language he created and I’m a fan of his personal philosophy, I’m always on the lookout for interviews of Bjarne Stroustrup. As far as I can tell, the most recent one is captured here: “An Interview with Bjarne Stroustrup | | InformIT“. Of course, since the new C++11 version of his classic TC++PL book is now available, the interview focuses on the major benefits of the new set of C++11 language features.
For your viewing pleasure and retention in my archives, I’ve clipped some juicy tidbits from the interview and placed them here:
Adding move semantics is a game changer for resource (memory, locks, file handles, threads, and sockets) management. It completes what was started with constructor/destructor pairs. The importance of move semantics is that we can basically eliminate complicated and error-prone explicit use of pointers and new/delete in most code.
TC++PL4 is not simply a list of features. I try hard to show how to use the new features in combination. C++11 is a synthesis that supports more elegant and efficient programming styles.
I do not consider it the job of a programming language to be “secure.” Security is a systems property and a language that is – among other things – a systems programming language cannot provide that by itself.
The repeated failures of languages that did promise security (e.g. Java), demonstrates that C++’s more modest promises are reasonable. Trying to address security problems by having every programmer in every language insert the right run-times checks in the code is expensive and doomed to failure.
Basically, C is not the best subset of C++ to learn first. The “C first” approach forces students to focus on workarounds to compensate for weaknesses and a basic level of language that is too low for much programming.
Every powerful new feature will be overused until programmers settle on a set of effective techniques and find which uses impede maintenance and performance.
I consider Garbage Collection (GC) the last alternative after cleaner, more general, and better localized alternatives to resource management have been exhausted. GC is fundamentally a global memory management scheme. Clever implementations can compensate, but some of us remember too well when 63 processors of a top-end machine were idle when 1 processor cleaned up the garbage for them all. With clusters, multi-cores, NUMA memories, and multi-level caches, systems are getting more distributed and locality is more important than ever.
One Step Forward, N-1 Steps Back
For the purpose of entertainment, let’s assume that the following 3-component system has been deployed and is humming along providing value to its users:
Next, assume that a 4-sprint enhancement project that brought our enhanced system into being has been completed. During the multi-sprint effort, several features were added to the system:
OK, now that the system has been enhanced, let’s say that we’re kicking back and doing our project post-mortem. Let’s look at two opposite cases: the Ideal Case (IC) and the Worst Case (WC).
First, the IC:
During the IC:
- we “embraced” change during each work-sprint,
- we made mistakes, acknowledged and fixed them in real-time (the intra-sprint feedback loops),
- the work of Sprint X fed seamlessly into Sprint X+1.
Next, let’s look at what happened during the WC:
Like the IC, during each WC work-sprint:
- we “embraced” change during each work-sprint,
- we made mistakes, acknowledged and fixed them in real-time (the intra and inter-sprint feedback loops),
- the work of Sprint X fed seamlessly into Sprint X+1.
Comparing the IC and WC figures, we see that the latter was characterized by many inter-sprint feedback loops. For each step forward there were N-1 steps backward. Thus, TWC >> TIC and $WC >> $IC.
WTF? Why were there so many inter-sprint feedback loops? Was it because the feature set was ill-defined? Was it because the in-place architecture of the legacy system was too brittle? Was it because of scope creep? Was it because of team-incompetence and/or inexperience? Was it because of management pressure to keep increasing “velocity” – causing the team to cut corners and find out later that they needed to go back often and round those corners off?
So, WTF is the point of this discontinuous, rambling post? I dunno. As always, I like to make up shit as I go.
After-the-fact, I guess the point can be that the same successes or dysfunctions can happen during the execution of an agile project or during the execution of a project executed as a series of “mini-waterfalls“:
- ill-defined requirements/features/user-stories/function-points/use-cases (whatever you want to call them)
- working with a brittle, legacy, BBOM
- team incompetence/inexperience
- scope creep
- schedule pressure
Ultimately, the forces of dysfunction and success are universal. They’re independent of methodology.
The Least Used Option
“We need to estimate how many people we need, how much time, and how much money. Then we’ll know when we’re running late and we can, um, do something.”
OK, assuming we are indeed running late and, as ever, “schedule is king“. WTF are our options?
- We can add more people.
- We can explicitly or (preferably) implicitly impose mandatory overtime; paid or (preferably) unpaid.
- We can reduce the project scope.
The least used option, because it’s the only one that would put management in an uncomfortable position with the customer(s), is the last one. This, in spite of the fact that it is the best option for the team’s well being over both the short and long term.
Schmuckers?
Ooh, ooh. Look at the picture that I snapped whilst on vacation. Expectedly, the sign “protected” the first parking spot next to the restaurant entrance. I’d speculate that it’s a great place to work, wouldn’t you?
Posing For The Camera
That tweet was triggered by this exchange within the confines of one of the C++ LinkedIn.com groups:
Now granted, BD00 may come across as being a poser to some/many, but he actually tries to fend off the strong, innate desire to impress others with his self-proclaimed “expertise“. Of course, as the content of this blog confirms, he often fails miserably. How about you? How often do you find yourself posing for the camera?
Connected By Assumptions
“The connections between modules are the assumptions which the modules make about each other.” – David Parnas
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 