Archive
Recursive Behavior
Information hoarding by individuals and orgs used to lead to success in the past, but information sharing is one necessary but insufficient key to success today.
In this century, if the dudes in the penthouse at the top of the pyramid keep all the good stuff locked up in the unspoken name of mistrust, it’s highly likely that this anti-collaborative behavior will be recursively reproduced down the chain of command. Hell, if that behavior led to success for the corpo SCOLs and CGHs, then it will work for the DIC-force too, no?
“Trust is the bandwidth of communication.” – Karl-Erik Sveiby
Clever And Mistake-Free
In “The 3 rules of mindsets”, Daniel Pink provides these examples in order to contrast fixed minded thinkers with growth minded thinkers:
- Fixed mindset: Look clever at all costs.
- Growth mindset: Learn, learn, learn.
- Fixed mindset: It should come naturally.
- Growth mindset: Work hard, effort is key.
- Fixed mindset: Hide your mistakes and conceal your deficiencies.
- Growth mindset: Capitalize on your mistakes and confront your deficiencies.
I don’t know about you, but I’m constantly struggling against the “Look clever at all costs” and “Hide your mistakes..” fixed mindset maladies. It’s easy to criticize the “environment” for these shortcomings, but ultimately it’s a personal ego battle, no?
Start Big?
While browsing through the “C++ FAQs“, this particular FAQ caught my eye:
The authors’ “No” answer was rather surprising to me at first because I had previously thought the answer was an obvious “Yes“. However, the rationale behind their collective “No” was compelling. Rather than butcher and fragment their answer with a cut and paste summary, I present their elegant and lucid prose as is:
Small projects, whose intellectual content can be understood by one intelligent person, build exactly the wrong skills and attitudes for success on large projects…..The experience of the industry has been that small projects succeed most often when there are a few highly intelligent people involved who use a minimum of process and are willing to rip things apart and start over when a design flaw is discovered. A small program can be desk-checked by senior people to discover many of the errors, and static type checking and const correctness on a small project can be more grief than they are worth. Bad inheritance can be fixed in many ways, including changing all the code that relied on the base class to reflect the new derived class. Breaking interfaces is not the end of the world because there aren’t that many interconnections to start with. Finally, source code control systems and formalized build procedures can slow down progress.
On the other hand, big projects require more people, which implies that the average skill level will be lower because there are only so many geniuses to start with, and they usually don’t get along with each other that well, anyway. Since the volume of code is too large for any one person to comprehend, it is imperative that processes be used to formalize and communicate the work effort and that the project be decomposed into manageable chunks. Big programs need automated help to catch programming errors, and this is where the payback for static type checking and const correctness can be significant. There is usually so much code based on the promises of base classes that there is no alternative to following proper inheritance for all the derived classes; the cost of changing everything that relied on the base class promises could be prohibitive. Breaking an interface is a major undertaking, because there are so many possible ripple effects. Source code control systems and formalized build processes are necessary to avoid the confusion that arises otherwise.
So the issue is not just that big projects are different. The approaches and attitudes to small and large projects are so diametrically opposed that success with small projects breeds habits that do not scale and can lead to failure of large projects.
After reading this, I initially changed my previously un-investigated opinion. However, upon further reflection, a queasy feeling arose in my stomach because the implication of the authors is that the code bases on big projects aren’t as messy and undisciplined as smaller projects. Plus, it seems as though they imply that disciplined use of processes and tools have a strong correlation with a clean code base and that developers, knowing that the system will be large, will somehow change their behavior. My intuition and personal experience tell me that this may not be true, especially for large code bases that have been around for a long time and have been heavily hacked by lots of programmers (both novice and expert) under schedule pressure.
Small projects may set you up to drown later on, but big projects may start to drown you immediately. What are your thoughts, start small or big?
Static Vs Auto Performance
Assume that you’re writing a function that’s called every 5 milliseconds (200 Hz) in a real-time application and that thread-safety for this function is not a factor (it will be called only within one thread of control). Next, assume that you need to use one or more temporary objects to implement the logic in your function. Should you instantiate your objects as static or as auto on the stack?
Unless I’ve made a mental mistake, the source code and results below confirm that using static objects is much more efficient that using auto objects. The code measures the time it takes to instantiate 10 million static and auto objects of type std::ostringstream. The huge performance difference makes sense since the static object is only constructed during the first function call while the auto object is instantiated 10 million times.
It’s likely that std::ostringstream objects are large, but what about small, simple user types? The code below attempts to answer the question by showing that the performance difference between static and auto is still substantial for a trivial object like an instance of class A. I’ve been using this technique for years, but I’ve never quantitatively investigated the static vs auto performance difference until now.
I was motivated to perform this experiment after reading the splendid “Efficient C++“. In the book, authors Bulka and Mayhew show the results of little experiments like these for various C++ programming techniques and idioms. Unlike most classic C++ books, which sprinkle comments and insights about performance tradeoffs throughout the text, the entire book is dedicated to the topic. I highly recommend it for fledgling and intermediate C++ programmers.
Are You Still Working On That?
It’s funny enough when you work for a one dimensional manager (one dimension = schedule), but it’s even funnier when another 1D manager that has nothing to do with your project stops by to chit chat and he/she inevitably asks you:
Are you still working on that?
LOL! Being 1D, and even though he/she has no idea what it takes (or should take) to finish a project, the question can be interpreted as: Since you’re not done, you’re lazy or you’re screwing up.
When the question pops up, try this Judo move:
Should I be done? How long should it have taken?
Or, you can be really nasty and retort with:
Yes I am still working on it. Sorry, but it’s not a shallow and superficial management task like signing off on a document I haven’t read or attending an agenda-less meeting that I could check off on my TODO list.
Come on, I dare you.
Fierce Protection
Delicious, just delicious. Pitches from Fred Brooks, Scott Berkun, Tom DeMarco, Tim Lister, and Steve McConnell all in one place: the Construx (McConnell’s company) Software Executive Summit. You can download them from here: Summit Materials.
Here’s a snapshot of one of Fred Brooks’s slides that struck me as paradoxical:
So…. who’s the “we” that Fred is addressing here and what’s the paradox? I’m pretty sure that Fred is addressing managers, right? The paradox is that he’s admonishing managers to protect great designers from…… managers. WTF?
But wait, I think I get it now. Fred is telling PHOR managers to “fiercely” protect designers from Bozo Managers (but in a non-offensive and politically correct way, of course). Alas, the fact that this slide appears at all in Fred’s deck implies that PHORs are rare and BMs are plentiful, no?
How do you interpret this slide?
Aggressive Substitution
One incredibly overused word heard repeatedly like a metronome across the vast corpo wasteland is “aggressive“. We will “aggressively pursue new opportunities“, “aggressively cut costs“, yada, yada, yada. It’s most commonly used by anointed BMs everywhere in long winded inspirational sentences that contain its most beloved twin: “schedule“. Here’s what my corpo jargon decoder ring tells me what it means:
Aggressive Schedule (AS) = Work your ass off at least 12 hours a day for months on end without receiving any overtime pay and expecting the same 1% yearly raise as the rest of the DICforce that smartly exits the psychic prison after five to seven hours of work per day. Oh, and I’ll get a bonus if you meet schedule.
The AS(s) phrase is always wielded by someone with no real skin in the game except for the possibility of fewer stock options if the “S” isn’t met. Since chronic overuse of any word takes the sting out of it, how about creatively mixing it up from time to time with a synonym replacement:
- Barbaric schedule
- Contentious schedule
- Destructive schedule
- Disruptive schedule
- Disturbing schedule
- Intrusive schedule
- Pugnacious schedule
- Rapacious schedule
I can’t decide on my favorite surrogate replacement. It’s either “pugnacious” or “rapacious”. What’s yours?
Blind, Ignorant, Deaf
In “The Thought Leader Interview“, HCL Technologies CEO Vineet Nayar describes his shocking “Employees First, Customers Second” method of management to a pair of Strategy+Business magazine reporters. In keeping with my biased approach of culling only those quotes and passages that support my view of what the wildly successful company of the future looks like, I’ve assembled this self-serving list for your consideration:
Somebody said to me about the Employees First program, “Vineet, your competitors will copy this, and therefore, it will not be a differentiator.” My response was, “If our competitors can post the results of 360-degree evaluations, more power to them.”
The moment the recession hit we went out to our employees and said, “We have a problem. We’re going to solve it together.” We had thousands of ideas coming in, and we implemented them. Most of them were operational: There were no new products, services, geographies, or contracts. But HCL grew 23 percent and increased global market share by 21 percent. Our employees felt they were a part of everything we were doing, because of our inclusive approach. Even if it may take a bit longer to arrive at decisions, this approach helps ensure that implementations are smooth and that initiatives are sustained after the initial hype.
We created a 360-degree process where anybody can give feedback to anybody, including to me. We post the results internally so that all employees can see them. Good or bad, we all learn from the results. It’s open, it’s transparent, and the impact is positive. We find that this practice is motivating people to change their behavior. They try harder.
We also looked for symbolic ways to be a model of openness. One thing I did was publicly dance in front of all my employees. This was to remove the halo that a CEO has around his head. Meaningful conversation happens after you have set the stage in this way, after you make clear that you are as open as anyone else — crazy but effective.
So I held an open house with a group of employees. “I’m feeling pretty bad,” I said. “Nobody is saying what is positive about our company. Do you think I’ve unlocked a genie that is spreading demotivation?” Their answer was interesting. They said it is good to wash dirty linen in public, in this case on the blog, because it builds trust. There are no rumors. We discuss everything openly and honestly. We don’t always have solutions to problems, but at least we expose them.
Whatever trust is left in command-and-control management structures has been deeply tested during the recession. I am told that in business in general, employee trust in management is at its lowest point ever.
Even though Mr. Nayar is a breath of fresh air, I’m not too optimistic that his ideas on effective corpo governance will spread like wildfire to a company near you. You see, Ricardo Semler, CEO of Semco Inc., was Vineet Nayar twenty years before Vineet Nayar. Of course, since Mr. Semler’s version of participative management was also an all out assault on the draconian, patriarchical, system of management that pervades the globe today, he was ignored by mainstream business too.
Disconnect And Distance
If professional social networks like LinkedIn.com were around in the 1980’s, it’s highly likely that you’d be branded as an unloyal traitor for joining one. Even today, didn’t you feel a slight twinge of exhilarating fear when you joined? Uh, not me (LOL!).
If the leaders (or should I say the “SCOL“s?) in your org are ostriches and they cling to outdated, mechanistic, FOSTMA ideas like the demand for one way loyalty without even a hint of self awareness that they need to change their mindsets, then head for the hills because your sugar daddy is most likely going downhill. If, for some reason beyond your control you think you’re stuck where you are, then simply disconnect and distance yourself from the daily shenanigans that take place in your environment.
Rabble-Rousing And Anarchy-Instigation
Because he’s passionate, energetic, and prolific, I like Tom Peters. Check out this twitter conversation I recently had with him:
What are your thoughts?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 