The Mother Of All Fiscal Catastrophes?
In 1998, the U.S. treasury and the federal reserve facilitated a $3.6B bailout of the Long Term Capital Management Fund (LTCM) hedge fund by 16 Wall St. banks. No taxpayer funds were used in the bailout.
Ten years later, in 2008, the U.S. treasury bailed out a slew of Wall St. institutions with 100s of billions of dollars in U.S. taxpayer money.
Famous doom-and-gloomers James Rickards and Peter Schiff predict that the next financial crisis, which will be the mother of all global fiscal catastrophes, will require that the U.S. government be bailed out by the International Monetary Fund. In this black swan scenario, the U.S. dollar will be replaced by the IMF’s SDR (Special Drawing Rights) as the world’s reserve currency and America’s reign as the world’s greatest superpower will come to an end.
I’m not convinced that Rickards and Schiff are right, but they do make a somewhat compelling case – enough so that it makes me feel “uncomfortable” whenever I see or hear them speak about it. Even if you think they are both batshit crazy, you might want to think of adding a touch of gold, silver, Bitcoin, or some other cryptocurrency to your portfolio…. just in case America fails to become great again.
You Have Just Crossed Over Into…
Assume that you’re actively working on a successful software development project before the Agile manifesto was created/signed and before Scrum was formally defined by Sutherland/Schwaber. The timeline and parameters of your project may look like this:
The number of managers and developers involved in the day-to-day work is most likely fixed and no executives directly meddle with the team’s internal affairs. In addition, the average number of hours worked per week per team member and the average stress level felt by the team is most likely constant. Most importantly, status reviews aren’t conducted on a daily basis. Once or twice a week is the norm. Because of the lack of a mandated daily status meeting, some healthy slack is available to the team for learning and doing things directly applicable to the project but not enumerated on the schedule/backlog. All is well, a healthy and sustainable pace is being maintained.
Now, imagine that at some point in the future of the project, someone in the executive suite decides (either rationally o irrationally) that the project is either behind schedule or over budget or, most likely, both. When that fateful day arrives, you will be suddenly transported into…. The Micromanagement Zone (TMZ):
The project timeline will most likely transition to this:
The consequences of transitioning into TMZ are never good for anyone involved (developers, managers, executives, customers):
- The frequency of status meetings will rise – most likely to at least one per day.
- The number of managers assigned to “oversee” the project will rise.
- One or more executives will get intimately involved in the day-to-day execution of the project.
- Some additional number of newbie developers may be suddenly injected into the team, bringing progress to a crawl.
- The number of hours worked per week per developer will rise.
- “Sustainable pace” will never be uttered again. The workaholics on the team will brag about toiling late into the night and on weekends.
- The average stress level will rise and the average physical health of the team will deteriorate.
The worst thing about entering TMZ is that it’s like a black hole: once you’re in, you can never escape. Well, that’s not quite true. You can leave of your own free will or the project may get cancelled.
So, how does Agile and/or Scrum solve this stubbornly entrenched and globally ubiquitous MZ problem? It doesn’t. In fact, every Agile/Scrum project is poised from the get-go to glide into the MZ as soon as the project is “deemed in trouble“. The fact that daily status meetings (promoted innocently in the Agile world as informally loose “standup” meetings) are required from day one points every Agile project directly toward the MZ abyss – all signed up and ready to jump. In the pre-agile days, daily status meetings were only initiated after the project was deemed in trouble, they weren’t required from day one.
The agile folks will say that the purpose of the daily standup meeting is to provide early warning detection of a project that is heading for trouble – and they can be right. They’ll also say that early detection will allow actions to be taken to get the project back on track – and they can be right. However, the specific “actions” taken to reign in the project may actually be those that will thrust the project squarely into the MZ .
Explaining Vs Training
I haven’t ranted against the software con$ultant industry in a while, so I decided that now is as good as ever to do it again. To that end, I submit Twitter exhibit A to the jury:
I guess that “explaining” how to do a stand up meeting to executives in which 3 simple questions are asked/answered only takes 5 minutes, but “training” them how to do it takes an intensive, four day on-site course at $2K per day… plus expenses.
As a general observation, consultants love to make the obvious and mundane look like a complicated and unfathomable hairball that only they can unravel for you, at a “fair” price.
The Reverse Butterfly Effect
Lipstick On A Pig?
Since the anecdotal evidence that I’ve seen over the years is overwhelming, I have absolutely no doubt that when Scrum is applied in the right context (e.g. small projects in unregulated industries), it works well for both managers and developers. However, when Scrum is either not applicable, or, more likely, starts out well and then degenerates over time into a textbook case of micromanagement, it reminds me of the lipstick-on-a-pig metaphor. When that perverse inversion occurs, the management team walks around touting “we’re agile“, and the development team simply….. walks around.
The “unsigned” Conundrum
A few weeks ago, CppCon16 conference organizer Jon Kalb gave a great little lightning talk titled “unsigned: A Guideline For Better Code“. Right up front, he asked the audience what they thought this code would print out to the standard console:
Even though -1 is obviously less 1, the program prints out “a is not less than b“. WTF?
The reason for the apparently erroneous result is due to the convoluted type conversion rules inherited from C regarding unsigned/signed types.
Before evaluating the (a < b) expression, the rules dictate that the signed int object, a, gets implicitly converted to an unsigned int type. For an 8 bit CPU, the figure below shows how the bit pattern 0xFF is interpreted differently by C/C++ compilers depending upon how it is declared:
Thus, after the implicit type conversion of a from -1 to 255, the comparison expression becomes (255 < 1) – which produces the “a is not less than b” output.
Since it’s unreasonable to expect most C++ programmers to remember the entire arcane rule set for implicit conversions/promotions, what heuristic should programmers use to prevent nasty unsigned surprises like Mr. Kalb’s example? Here is his list of initial candidates:
If you’re trolling this post and you’re a C++ hater, then the first guideline is undoubtedly your choice :). If you’re a C++ programmer, the second two are pretty much impractical – especially since unsigned (in the form of size_t) is used liberally throughout the C++ standard library. (By the way, I once heard Bjarne Stroustrup say in a video talk that requiring size_t to be unsigned was a mistake). The third and fourth guidelines are reasonable suggestions; and those are the ones I use in writing my own code and reviewing the code of others.
At the end of his interesting talk, Mr. Kalb presented his own guideline:
I think Jon’s guideline is a nice, thoughtful addition to the last two guidelines on the previous chart. I would like to say that “Don’t use “unsigned” for quantities” subsumes those two, but I’m not sure it does. What do you think?
Plugging Those Leaks
It’s been 5 years since modern C++ arrived on the scene in the form of the C++11 standard. Prior to the arrival, C++ was notorious for memory leaks and segmentation faults due to the lack of standardized smart pointers (although third party library and home grown smart pointers have existed for decades). Dangerous, naked news and deletes could be found sprinkled across large code bases everywhere – hidden bombs waiting to explode at any moment during runtime.
I don’t know how many over-confident C++ programmers are still using the old new/delete pattern in new code bases, but if your team is one of them please consider hoisting this terrific poster on the walls of your office:
ISO WG-21 C++ committee convener Herb Sutter, a tireless and passionate C++ advocate for decades, presented this poster in his CppCon 2016 talk “Leak Freedom In C++: By Default“. Go watch it now.
From Daily Standup To Daily Inquisition
Tis’ what it is. We live in the REAL world.
Advice That Transcends Time
Please take a moment to temporarily push all you’ve learned about large-system software development on the stack in your brain and imbibe some timeless advice from this thoughtful, 1992, NASA report: “Recommended Approach To Software Development“:
Ok, now that you’re done processing what you’ve just seen, you can pop the stack.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 