Teamwork's Just Another Word for Shifting Blame

Lyrics aren't TheHackerCIO's profession, but I'm sore tempted to write them about the evil Idol of "Teamwork." Perhaps, to the tune of that old standard, "Me & My Bobby McGee." Something like:

 "Shifting blame was easy, Lord, when we were screwed and blued ..." 

Or, 

"Teamwork's just another word for Shifting All the Blame ... "

I know whenever I hear people singing praise to "Teamwork," that 5-9s of the time (i.e., 99.999%, for those of you unused to uptime claims), they are euphemistically referring to a Blame-shifting subterfuge, rather than a productive collaborative effort. 

Recently, for example, Beth Comstock angered TheHackerCIO with her conventional Whiz-Dumb -- so typical of the Bureaucratic Hidebound Enterprise (where TheHackerCIO has unfortunately spent the majority of his career) -- that "There is No Lone Genius; Hire a Team". 

Which, in response, elicited my very popular posting, Never Hire the Greatest Scientist The World Has Ever Known, mostly focused on Newton, but which could just as well be generalized to "Never Hire the Greatest Minds the World Has Ever Seen," and broadened to include many other notables, including Rene Descartes, or, in more modern times,  Einstein, who noted of himself:

"I am a horse for a single harness, not cut out for tandem or teamwork; for well I know that to attain any definite goal, it is imperative that one person should do the thinking and commanding" [ref: here]

Can you envision the HR department interview? So, Mr. Einstein, are you a Team player? 

So many today seem to worship at the alter of the "Team Player." In my experience, the "Team Player," is either one who is too junior to work independently, without senior direction and supervision, or one who wishes to have others involved in his work products, so that blame is either difficult to assess or to attribute to one agent. I can't really see any other advantage to it. 

As the reference cited notes, this also was the belief of Descartes, the founder of Analytic Geometry among myriad other things. He noted in his Meditations, as summarized here, that:

"the works of individuals are superior to those conceived by committee because an individual’s work follows one plan, with all elements working toward the same end. He considers that the science he learned as a boy is likely flawed because it consists of the ideas of many different men from various eras." 

Frankly, anyone can verify these claims very simply: just sit on a committee. Almost any committee will do. But, especially, on a "Steering Committee." You wouldn't allow a committee to steer your car, bus, or plane, but suddenly everyone goes mystically silent when someone proposes the same thing for directing hundreds of millions of dollars worth of technology and equipment. Wreckage everywhere is the result, uniformly. 

None of this means that there isn't value to be found from collaboration. But, the benefit that does accrue comes from and is made possible by the individual achievement of the actors involved. Individual achievement is a "basic." It's a fundamental. It's a basis, on top of which collaborative synergies can layer in and develop. To put that down is to destroy the very underpinnings of achievement. Only an HR department can do that effectively. 

I Remain, With Single Harness, 

TheHackerCIO 

Thumbs Up From Early Feedback

My colleague with a newborn celebrated the little one's first month "birthday," which is something I never did with my children.  But, since this is a brainchild, I see no reason not to be overly doting and celebrate the first month of TheHackerCIO's blog!

As of 3:01pm, it's been a month!

Much has been accomplished already.

A reasonably varied sampling of content is now available: of interest to CIO types, entrepreneurs, startups, and hackers.

The overall flavor of TheHackerCIO is now well established.

It's time to think about promoting TheHackerCIO.

Unsurprisingly, the general interest postings are the most popular. In order from most to less:

1. Never Hire the Greatest Scientist the World Has Ever Known
2. Why Hackers Hate Headhunters and its followup posting: An "Attractive" Salary 
3. The ever popular, and extraordinarily brief, Who is TheHackerCIO?
4. My favorite: Why the CIO Must Also Be a Hacker, which further explains #3 above.

The first week of this blog's life virtually no-one knew about it. It was a question of providing writing samples. From the second week on, I notified those with whom I am "LinkedIn," and a few selected technical Meetup and Forums which I attend.

It is gratifying that I have received over  2114 Pageviews -- that's an average of over 70 pageviews/day. Interestingly, these come from Malta, France, the UK, China, Portugal, Canada, and Australia. I didn't expect that.

Early reviewers of my blog are giving me a "thumbs up."

CIO-types, Hackers, and Entrepreneurs  are all very positive. If, as the example I excerpted below, I have a "great blog," am worthy of promotion, answer the questions people want to ask, and have good reviews of books -- then I have accomplished exactly what I set out to do, and then some. Which doesn't surprise TheHackerCIO, at all.

Representative examples to support my claim ...

----------------------------------------------------------------------------------------------------------------------------------
1. Ilya Pozin, Serial Entrepreneur, columnist for Forbes, & Inc. Magazine:

James -

Great blog! If you have an article that you post that you feel is a good fit for my followers, I'll be more than glad to promote it on LinkedIn and Twitter!

<<snip>>

Ilya Pozin

Founder and CEO, Open Me (coming soon!)

Founder, Ciplex a web marketing agency

Columnist, Inc., Forbes, & LinkedIn

Inc. 30 Under 30

----------------------------------------------------------------------------------------------------------------------------------
2. A Director of IT

Hi James,

I like your blog. You have a unique background so what you say cuts across many aspects of technology. You answer the questions I want to ask.

Regards,
Stephen

-------------------------------------------------------------------------------------------------------------------------------------------------------------------
3. A Geeky Book Club Colleague:

 George ... <name snipped>  wrote:


<<snip>>

Anyway, I thought the part about avoiding the 404 error with the 1x1 blank pixel was cool. Is this a 404 that actually appears on their screen?  I have never seen that.

Good review of the performance book (which I am skipping).

Cheers!   George 

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Many thanks to my regular readers, and I intend to continue producing interesting postings for your reading pleasure. Because your reading pleasure is my writing pleasure!

I Remain,

TheHackerCIO

Bookishness & Geekiness

Internally I think of it as "My Geeky Book Club." And so I refer to it with my wife. But, the official name is LAJUG Study Group,  and last night the remaining faithful few finished up the Performance Book:

 Java Performance by Charlie Hunt and Binu John

Now, our group will take a little break, and read a few articles, specifically: 

• Hackers & Painters: by Paul Graham
• The top 9+7 things every programmer or architect should know: by Brian Du Preez

Paul Graham is a Technologist everyone should know about. Read his essays, if you haven't already. The link above will give you a start. He's a successful entrepreneur and now runs Y-Combinator , which is the best incubator for tech startups to get into. Not so much for the money -- you won't get that much -- but for the in-house expertise on starting tech companies, which is incomparable, and invaluable. 

Invaluable, in that it can't be valued, because it's value is too high. That's one of those problem words that always bothers me, because there are other reasons I can think of why something might be invaluable. For instance, working at a multi-billion dollar enterprise is experience that is invaluable: it can't be valued, because it is worthless. They lied about their desire to transform their technology, or at any rate they have no serious desire to step outside of their comfort zone and really accomplish much of anything. So the time spent working there and the experience overall is invaluable. This is another word to put on my list of peculiar english expressions along with inflammable, which means flammable! But we don't want to get confused here and we need to get back to geekiness and books and articles!

After next weeks session on the two articles linked above, we'll move into BDD and Cucumber. My copy has arrived from Amazon, but I haven't imbibed yet. So comments will have to come later.

As to last nights discussion, none of us are too enamored with the Performance Book, so we ventured fairly wide in our chatting.

One early topic was a comparison of several books from the past, and what was learned from them.  I noted that the Azul presentation, in my view, was far superior to this book. I felt that the Azul presentation answered questions and raised my understanding about Java Performance and Garbage Collection. In contrast, while this book answered some questions and improved my understanding somewhat, for everything I learned, I became aware of ten more questions, issues, and conditioning factors, which were NOT explained. Thus I was left with the feeling that in some sense I knew less than what I started with. Yes, I had gained knowledge, but I had gained more awareness of how lacking that new knowledge was than I had gained in new knowledge. This is kind of a difficult point to explain succinctly, but the pattern is: to understand A, you must understand Q, R, S, T, U and V to enter into a proper comprehension of A and it's implications. And here is are a few more details about A. But in the meantime, if you want to know about Q, R, S, T, U, and V, please consult the references at the chapter end. That is the pattern of what I felt from reading through this Performance Book.

By contrast, with the Azul presentation, I learned basic principles, and then saw an analysis of existent JVMs in the context of those basic principles. That's an extraordinarily good structure for any presentation. And it didn't leave me with tons of unanswered nagging problems and issues.

Another member noted that with the Generics book, it had been confusing, and he concluded that the Java community should have "just said no" to Generics.  I've always found them confusing as well. And I prefer keeping a language simple. 

He also noted that with the Concurrency book, while many of the corner cases were disturbing, there were lots of tips and "don't go there" advice that was well worthwhile.

Then there was some discussion about NRU: Not Recently Used. That's kind of interesting, this this is distinguished from the LRU (Least Recently Used) algorithm with which we are all familiar. Apparently, NRU is less precise, but has less bookkeeping overhead. 

Everyone was kind of surprised to learn that with a Java start command (-XX LargePageSizeInBytes) you can alter the page size all the way up to a Gigabyte! Not sure when I'd want to do this, but it's quite interesting. Perhaps an application might be able to tune to page size. Have to think about that one.

On p. 549, we got hit with a countervailing opinion that "pessimistic locking may provide better performance." But the conventional Whiz-dumb has it that optimistic locking will provide better performance. We discussed this for some time and came to see that really it depends on what the statistical likelihood is of lock failure, in your particular environment. If you're likely to fail on a particular lock, then it actually improves performance if you pessimistically lock! But I don't think anyone ever notes this nearly obvious fact, or stops to consider what their particular environment likelihood of failure is. 

So, that wraps up a difficult, demanding, and marginally rewarding read. I'm still a better person for having worked through it. But I would really love to take the Azul presentation and compare it to the Book chapters on the JVM. Perhaps, if Azul provides us with their slides, I'll do that.

I Remain, Ever Reading, and Ever ...

TheHackerCIO

The Half-Hour, High-Availability Cluster!

Last nights Technology Radar Group tutorial was awesome! Kevin Epstein guided us through the live process of spinning up a load balanced HA cluster with an elastic growth of between 2 and 10 instances. He began with a slide presentation classifying all the many products that make up the Amazon Web Services constellation of products. Then, he used the AWS Console to create a base instance with a MySql database and quickly set up a WordPress blog. An awesome blog, that the whole world will want to view, which will result in performance problems for the server!!! Well, OK, you have to use your imagination for that part, but he did set up a basic blog page and displayed the IP of the underlying instance, so we could verify what was going on in the demo.

One particularly interesting twist was his use of Route53 for a simple failover mechanism. He configured this so that it was checking for the health of the server, which in the beginning, had not yet been created! Since non-existence is kind of a "bad health" state, the Route53 failed over to an S3 bucket, and displayed some static content. Once he started the instance, this  no longer failed over and the static content was no longer displayed, since the actual blog replaced it.

Next on the menu was replacing the database embedded in the instance with a Amazon Services database -- that is to say, an RDS service. He used the same MySql database engine for this, and used MySql utilities to dump the data to a flat file and then import it into what was now a clustered, backed-up database!

After the break he configured an ELB and an autoscaling group.  His comments throughout this presentation were most helpful. For instance, he commented on the phenomenon of "flapping," where  the failure heartbeat is set to too short a period. In such cases, one can produce a worse outcome than the brief outage that comes from failover, by repeatedly failing over, and failing back, with the user still experiencing a repeated loss of transactional state.

He also, most helpfully, pointed out that in creating the "Gold Image" instance, from which the cluster would be initiated, you NEVER want to choose the "No Reboot" option! In the normal case, you want to ensure a consistent state on the image you are copying, so it has to be an unbelievably weird scenario where you would want to save the tiny bit of time possible by taking a snapshot without a reboot first. If anyone knows such a scenario, please send it on in, so we can take note of that rare, exceptional condition. In the meantime just leave that checkbox alone!

The cluster he defined was a "Multi-AZ" or Multi-Availability Zone cluster, which in AWS terms is an High Availability cluster. He noted that this was one area where the AWS console was insufficient, and the one had to resort to either the command line, or use a third party tool. The tool he preferred was called ElasticWolf. But there was some kind of issue in seeing the instances and we were under time pressure, so he resorted to using ezautoscaling, which is another third-party tool, and a good one, but one that charges.

I like complex live presentations precisely because they often run into problems: you get to see a problem arise, and a work-around employed! That's invaluable experience, and to get it vicariously is a tremendous boost  -- it gives a beginner some inkling of how to work/struggle with a new product. And what do we do every day, but struggle with technology? Nothing comes easy in the tech world!

For anyone interested, I highly recommend the Los Angeles AWS Users Group, which joined together with the Technology Radar Group us for this tutorial presentation. We are also very lucky to have Eric Hammond's blog Alestic. Eric is a member, and regular attender at the AWS Users Group. If you haven't read Eric's blog, you're missing out! And special thanks go to Kevin Epstein for a masterful presentation. One commenter claimed this was our best Meetup presentation yet, and I agree with him!

Presentation Slides
Screencast of Tutorial (Will be provided a link here, when available)

Technology Radar Group Tonight!

Tonight at 7pm, will be the third meeting of the Technology Radar Group Meetup. We're anticipating over 30 attendees -- pretty good for a Meetup only a few months old!

Tonight will focus on Amazon Web Services. It will be a showcase/tutorial on how to spin up a load balanced server using ELB.

This is really just an announcement blogging -- if you're local to LA, please drop by. We'd love to have you, and it promises to be an exciting session. If you can't make it, we're attempting ... (no promises) ... attempting, that is, to get a screencast to post on the Web.

Details, and the signup for further announcements may be found here:

http://www.meetup.com/Technology-Radar-Group/

I Remain, Faithfully,

TheHackerCIO

GrandMaster With A White Belt

TheHackerCIO's Karate Dojo is very traditional. The GrandMaster says that for him, the clock stopped 4 decades ago! My daughter will be testing for BlackBelt this Spring in Kyoto, and, assuming she passes, which I have every confidence she will, she will return to Silicon Beach wearing a White Belt!

That's a tradition. Whenever someone achieves Black Belt, for one month, they wear a white belt. This is a reminder that they are far from finished with their studies. On the contrary, they are now able -- at last -- to study real Karate! And they need to "throw away their ideas" and focus afresh on what the GrandMaster is doing to start their new learning.

I can think of a half dozen applications of this principle to technology.

One of them is simply the fact that good technologists are always very aware of the their constant need to learn. And TheHackerCIO is no exception. Even if he is GrandMaster at Codojo, the consulting boutique he is launching, he still views himself as a White Belt. His personal motto is that "I am always a white belt."

The classical Greek civilization had a similar motto -- which perhaps led to their revolutionary development of every branch of knowledge. In their version, they would say, "For the Greeks are always children." The meaning was that they were newcomers to the civilized world -- compared, for instance, to Ancient Egypt. And as newcomers, they had a fresh perspective on everything.

Let everyone put on their white belt! "To fill the tea cup, you must first empty it." Throw away your preconceived notions, and examine new technology from the perspective of how it can best be used, following it's own internal design principles.

Go now, and put on your white belt!

I Remain,

TheHackerCIO

Why TheHackerCIO Doesn't Outsource

Every week outsourcing companies contact me. I get at least 4-5 emails and yesterday, a colleague I worked with 6 years ago called to offer outsourcing services!

TheHackerCIO doesn't do foreign outsourcing. 

I've heard anecdotal stories about wonderful success with foreign outsourcing. But, frankly,  anecdotal evidence is highly suspect to TheHackerCIO. I listen to it politely. I'm too kind to call they liars. But I don't accept it. Not for a moment. 

Not when I daily see the mess created by one such foreign outsourcer, who: 

• selected a package for the client, of which they use less than 5% of the functionality.
• wrapped JSON in XML-RPC, because they couldn't get the JSON to work end-to-end.
• misspelled variables all over the place, in code from which database column and table names were generated. That is where you CAN NOT fix them without unloading the database, altering the schema, reloading the database, and coordinating this with code changes. I am particularly unforgiving of this, because any decent IDE will flag a misspelled word. But now, these subtle misspellings are potential problems and errors in the code base. For the foreseeable future.

I also managed a foreign offshore team of twenty plus developers on a project for a major financial client on the East coast. When the code arrived to us, it was unusable. We scrapped it, and buttressed our on-shore team to quickly attempt a re-write. Particularly shocking was the fact that even the simple modules were messed up and needed rework. We gained absolutely zip from our foreign outsourcing attempt. 

TheHackerCIO would take the management blame if he deserved it. I proactively attempted to the best of my ability -- and frankly, to the best of anyone's ability -- to ensure that they understood the requirements and the special framework within which the code had to work. But to no avail.

At an LACTO Forum meeting, a specialist on foreign outsourcing told us that to be successful, you had to travel frequently over to the foreign site and spend face-time, do team-building, etc. That doesn't fit into the business model of a small boutique consulting firm. 

So, I believe that it possibly can be successful. Well, OK, I'll leave the jury out on that one. But even if it could be, the only way it could is completely unworkable in the context of my business. So, I'll pass on the Outsourcing. And thank you very much. 

If you depend upon quality, delivery time, or even just actual delivery, I can't imaging a higher-risk approach than outsourcing. In fact, I think the only reason it came into vogue was from Pointy Haired bosses who read about how much money could be saved by doing it. And who never had any success with it any time they ever employed it. 

TheHackerCIO says, "Just say no, to outsourcing."

I Remain,

TheHackerCIO