Archive

Posts Tagged ‘postaday2011’

Horse And Buggy

March 21, 2011 10 comments

Werner Vogels is Amazon.com’s Chief Technology Officer and author of the blog “All Things Distributed – Building Scalable And Robust Distributed Systems“. I just couldn’t stop myself from laughing when he announced that fellow distributed-systems guru Steve Vinoski had just joined Twitter:

Specifically, the last sentence put me in stitches. As you can see from the book cover below, Steve is a CORBA expert and way back in the dark ages he was a CORBA advocate. However, he’s moved into the 21st century and left that horse and buggy behind – unlike others who cling to their horse whips and ostracize those who point out the obvious.

Bug Reporting Rate

March 20, 2011 Leave a comment

My Erlang Learning Status – II

March 19, 2011 1 comment

In my quest to learn the Erlang programming language, I’ve been sloowly making my way through Cesarini and Thompson’s wonderful book: “Erlang Programming“.

In terms of the book’s table of contents, I’ve just finished reading Chapter 4 (twice):

As I expected, programming concurrent software systems in Erlang is stunningly elegant compared to the language I currently love and use, C++. In comparison to C++ and (AFAIK) all the other popularly used programming languages, concurrency was designed into the language from day one. Thus, the amount of code one needs to write to get a program comprised of communicating processes up and running is breathtakingly small.

For example, take a look at the “bentUML sequence diagram of the simple two process “echo” program below. When the parent process is launched by the user, it spawns an “Echo” process. The parent process then asynchronously sends a “Hello” message to the “Echo” process and suspends until it receives a copy of the “Hello” message back from the “Echo” process. Finally, the parent process prints “Hello” in the shell, sends a “Stop” message to the “Echo” process, and self-terminates. Of course, upon receiving the “Stop” message, the “Echo” process is required to self-terminate too.

Here’s an Erlang program module from the book that implements the model:

The go() function serves as the “Parent” process and the loop() function maps to the “Echo” process in the UML sequence diagram. When the parent is launched by typing “echo:go().” into the Erlang runtime shell, it should:

  1. Spawn a new process that executes the loop() function that co-resides in the echo module file with the go() function.
  2. Send the “Hello” message to the “Echo” process (identified by the process ID bound to the “Pid” variable during the return from the spawn() function call) in the form of a tuple containing the parent’s process ID (returned from the call to self()) and the “hello” atom.
  3. Suspend (in the receive-end clause) until it receives a message from the “Echo” process.
  4. Print out the content of the received “Msg” to the console (via the io:format/2 function).
  5. Issue a “Stop” message to the “Echo” process in the form of the “stop” atom.
  6. Self-terminate (returning control and the “stop” atom to the shell after the Pid ! stop. expression).

When the loop() function executes, it should:

Suspend in the receive-end clause until it receives a message in the form of either: A) a two argument tuple – from any other running process, or, B) an atom labeled “stop“.

  1. If the received message is of type A), send a copy of the received Msg tuple argument back to the process whose ID was bound to the From variable upon message reception. In addition to the content of the Msg variable, the transmitted message will contain the loop() process ID returned from the call to self(). After sending the tuple, suspend again and wait for the next message (via the recursive call to loop()).
  2. If the received message is of type B), self-terminate.

I typed this tiny program into the Eclipse Erlide plugin editor:

After I compiled the code, started the Erlang VM in the Eclipse console view, and ran the program, here’s what I got:

It worked like a charm – Whoo Hoo! Now, imagine what an equivalent, two process, C++ program would look like. For starters, one would have to write, compile, and run two executables that communicate via sockets or some other form of relatively arcane inter-process OS mechanism (pipe, shared memory, etc), no? For a two thread, single process C++ equivalent, a threads library must be used with some form of synchronized inter-thread communication (2 lockless ring buffers, 2 mutex protected FIFO queues, etc).

Note: If you’re interested in reading my first Erlang learning status report, click here.

I’ll Have A Double, Please

March 18, 2011 Leave a comment

When you’re given a customer problem:

do you create a solution like this:

or this:

Marshal Law

March 17, 2011 Leave a comment

In a time of crisis, some “leadership” experts promote imposing the corpo equivalent of marshal law via the execution of more top-down control and discipline in the form of more frequent, multi-layered, financial reviews and detailed status reporting.

The thinking behind the “more control” approach is that by shining the light more often, and at a higher intensity, on those directly-in-the-soup will cause the crisis to dissolve. Another unquestioned assumption behind the “more control” approach is that the light-shiners will be able to better understand the real problems behind the crisis and offer “helpful”  solution idea candidates – inspiring the troops to success.

Sounds great, right? Let’s switch gears, step into the deliciously diabolic role of devil’s advocate, and ask “what’s wrong with this picture?“. Are these thoughts missing:

  • those doing the shining may be responsible for the mess in the first place but don’t realize it.
  • those doing the shining have been so disconnected from the real world for so long that they are incapable of understanding the problem details well enough to help?
  • those being illuminated will batten down the hatches, narrow their thinking, and withhold important information if they think it can be used against them.

Nah, probably not. After all, it’s a no brainer that the best and brightest problem solvers and decision makers sit at the top of the pyramid. If you don’t believe me, simply ask them.

On the other hand, a different pool of leadership experts promotes the unintuitive loosening of controls and less formality in a time of crisis – to allow more ideas from more people to surface and have a chance of resolving the crisis. Which approach do you think has a better chance of success?

Don’t try to address difficulties by adding more meetings and management. More meetings plus more documentation plus more management does not equal more success. – NASA SW Dev Approach

Boss Building

March 16, 2011 Leave a comment

I recently stumbled upon this interesting NY Times article: “Google’s 8-Point Plan to Help Managers Improve”. Prior to developing their 8-point improvement plan, the management philosophy that propelled Google to superstar status was this:

“For much of its 13-year history, particularly the early years, Google has taken a pretty simple approach to management: Leave people alone. Let the engineers do their stuff. If they become stuck, they’ll ask their bosses, whose deep technical expertise propelled them into management in the first place.”

After collecting inputs from their vast workforce, a Google task force concluded that technical expertise in the management ranks was still important, but it ranked as the lowest priority on their list of desired manager attributes:

… Mr. Bock’s group found that technical expertise — the ability, say, to write computer code in your sleep — ranked dead last among Google’s big eight. What employees valued most were even-keeled bosses who made time for one-on-one meetings, who helped people puzzle through problems by asking questions, not dictating answers, and who took an interest in employees’ lives and careers.

“In the Google context, we’d always believed that to be a manager, particularly on the engineering side, you need to be as deep or deeper a technical expert than the people who work for you,” Mr. Bock says. “It turns out that that’s absolutely the least important thing. It’s important, but pales in comparison. Much more important is just making that connection and being accessible.”

So, let me summarize the management characteristics that Google will value most in the future.

  • Being accessible
  • Making time for one-on-one meetings and taking an interest in employee’s lives and careers.
  • Helping people by asking questions and not dictating answers.

Google’s conclusions weren’t earth shattering, but they’re hard to implement in orgs where bosses spend all of their time going to agenda-less meetings, cavorting with their meta-bosses, taking status from their direct reports, and dueling with their peers, no?

Judgment, Integrity, Credibility, Honesty, And $53M

March 15, 2011 Leave a comment

The often (but not always) incestuous relationship between hand picked corpo board of directors yes-men and CEOs has come to the fore again: “HP orders probe into Hurd’s departure”. Why would Hewlett Packard, as represented by its board of derelicts, I mean directors, investigate their own handling of Hurd’s dismissal? They’re not doing it because it’s the right thing to do. They’re only doing it because they’re being forced to:

“HP’s plan for an outside investigation follows a lawsuit in San Jose, Calif., by shareholders who allege that the company’s directors wasted money by giving Hurd $53 million in severance.”

Yepp, a gift of $53 million to Mr. Hurd for exhibiting:

A profound lack of judgment. It (Hurd’s dismissal) had to do with integrity, it had to do with credibility and it had to do with honesty.” – Mike Holston, HP’s general counsel

After doling out that kind of dough, can’t the same be said about HP’s board? Well, that’s what we may find out after the dust settles. In the meantime, HP’s board may have gotten what they deserved. Mr. Hurd has Madoff nicely by skidaddling over to one of HP’s biggest competitors, Oracle Inc. He and his buddy, Oracle oracle Larry Ellison, sure do know how to make money.

“Mark did a brilliant job at HP and I expect he’ll do even better at Oracle,” said CEO Larry Ellison in a statement.

The real question is: “How isolated are these types of incidents?“. Just because they get reported in the press doesn’t mean that dishonesty runs rampant in the bozone layers of big business. Nevertheless, it begs the question: “Is the taken-for-granted, rarely-questioned process in which CEOs and boards of directors are chosen broken?“. Boards anoint CEOs (who coincidentally are often the chairman of the board) and CEOs nominate board members for election. What do you think of the process? How can it be made better?

An Answer 10 Years Later

March 14, 2011 Leave a comment

I’ve always questioned why one of my mentors from afar, Steve Mellor, was one of the original signatories of the “Agile Manifesto” 10 years ago. He’s always been a “model-based” guy and his fellow pioneer agile dudes were obsessed with the idea that source code was the only truth – to hell with bogus models and camouflage documents. Even Grady Booch, another guy I admire, tempered the agilist obsession with code by stating something like this: “the code is the truth, but not the whole truth“.

Stephen recently sated my 10 year old curiosity in this InfoQ interview: “A Personal Reflection on Agile Ten Years On“. Here’s Steve’s answer to the question that haunted me fer 10 ears:

The other signatories were kind enough, back in 2001, to write the manifesto using the word “software” (which can include executable models), not “code” (which is more specific.) As such I felt able, in good conscience, to become a signatory to the Manifesto while continuing to promote executable modeling. Ten years on we have a standard action language for agile modeling. – Stephen J. Mellor

The reason I have great respect for Stephen (and his cohort Paul Ward) is this brilliant trilogy they wrote waaaayy back in the mid 80s:

Despite the dorky book covers and the dates they were written, I think the info in these short tomes is timeless and still relevant to real-time systems builders today. Of course, they were created before the object-oriented and multi-core revolutions occurred, but these books, using simple DeMarco/Plauger structured analysis modeling notation (before UML), nail it. By “it”, I mean the thinking, tools, techniques, idioms, and heuristics required to specify, design, and build concurrent, distributed, real-time systems that work. Buy em, read em, decide for yourself, bookmark this post, and please report your thoughts back to me.

Fully Qualified

March 13, 2011 2 comments

When I’m coerced into inheriting from one or more base classes to reuse pre-existing functionality, I prefer to fully qualify my calls to base class member functions like this:

Coding this way helps me to keep a conceptual separation between classes and eases downstream maintenance – I know where to look for the function definitions. Since I’m a “has a” instead of an “is a” programmer, I prefer black box composition over white box inheritance; unless it’s necessary or authoritative coercion is involved. How about you? What’s your preference?

Ego And Apathy

March 12, 2011 Leave a comment

The other day, my teammates and I had a short e-discussion on how much ego we should each personally invest in our code base. On the one hand, “no ego” can lead to apathy and a crappy, untended, code base. On the other hand, too much ego can trigger too many confrontational ego-battles and lead to a crappy, colliding styles, code base. We decided that there’s some sweet spot in the middle, but we don’t know what the freak it is. D’oh!

Historically, my personal style has been investing “too much ego“; which manifests as both offensive and defensive behavior. Being a devilishly clever (but certainly not smart) bloke, I’ve spent way more time offending than defending – cuz offense is much more fun to the ego. On the bright side, I think I have been slooowly getting betting over time, but it doesn’t really matter what I think.

How about you? Are you too apathetic? Too ego-dominated? Do you care?