With a Wimper

The other day I ate lunch with a colleague. She argued that training the entire company on The Oz Principle and having each employee participate in eight two hour evaluations each quarter was worth the expense and bother even if only she and I were inspired to demonstrate responsibility-taking behavior before our co-workers. My position was that not a single management fad I have ever witnessed emerging from the executive suite had had any impact on corporate culture or effectiveness. The Oz Principle walks like a duck, quacks like a duck and, more to the point, smells like a duck. The most disappointing part is that seasoned businessmen and women actually buy these books.

I have made no secret of my doubts about Agile Development. To be sure, my company showed all the signs of an Agile Failure environment - top heavy decision making, Agile by mandate, lack of top-level buy-in, a culture of just-get-by. You can't just flip a switch and change the corporate culture. Now, after only a few months, the course of events is unfolding exactly as I anticipated based on my two decades experience at various companies.

First, at the sprint planning session, the so-called User Stories are written based on the steps required to complete some system design that each developer holds in his or her head. Instead of "As a call center rep, I want ..." every card begins, "As a developer I need to ...". Since our product owner comes out of IT instead of the user organization (she says she KNOWS what they need) no one blinks. When I brought this up, I was told that according to some Agile books, this is allowed. I shut up after that. Next each user story is assigned a complexity based on an unstructured discussion in which the senior members of the team dominate - no input from the underlings. Finally, the programming manager, who is on the team, provides the task estimates and then assigns each task to a developer before the first sprint has even started!

Here's what has happened: the manager nixes any self-organization and the focus remains on IT delivering the functionality that they believe the user needs. To top it off, the higher-ups are demanding hard deadlines and treating every problem as a fire, yanking team members around like manic chess pieces. This process reflects the exact sequence of events that went into planning a project before we went all Agile. As I expected, the members of IT have found a way to do exactly what they were doing before but pay lip service to being Agile. It was that way at the phone company and it's that way now.

The challenge to management is to cancel their Management Book of the Month subscription, do some real research in organizational behavior, look hard at the culture they have to deal with and find creative, insightful ways to move the company out of the 1980's. Good luck.

Hate is the crucible of our values.

But for the Grace of God

I am listening to Sidney Poitier's book, The Measure of a Man. In the mod-50's, after making No Way Out, Cry Beloved Country and Blackboard Jungle, his only source of steady income to support his family was a failing rib restaurant. It finally got to the point where he asked his father-in-law to teach him how to lay bricks.

A man whom we would consider a quintescential success struggled to feed his family in the midst of that supposed success. Ain't hind-sight grand?

P.S.: He failed at bricklaying

Solid Ground?

Two seismologists, Meredith Nettles and Göran Ekström of Columbia University, discovered a few years ago that unusual earthquakes were emanating from the Greenland glaciers as they dumped the extra ice into the sea. “It’s remarkable that an iceberg can do this, but when that loss of ice occurs, it does generate a signal that sets up a vibration that you can record all across the globe,” Dr. Nettles said in an interview in Greenland.

Analyzing past records, they discovered that these quakes had increased severalfold from the level of the early 1990s, a sign of how fast the ice is changing.

As Glaciers Melt, Science Seeks Data on Rising Seas, NY Times, Nov 13

We like to think we are standing on solid ground. The glacial pace of plate tectonics (pun intended!) makes it a bit too remote to affect our daily experience. On the other hand, when I reflect on forebulging, the lifting up of the earth's crust around continental icesheets of the ice age caused by the weight of the icesheet pushing down on the crust under it. It is like sitting on a couch and noting the "ripple" of cushion around your rear end.

Now I read here that losing just a bit of ice from a glacier is enough to trigger a shifting in the earth's surface, heard via seismograph. It kinda makes me feel humble in the face of forces and movements far beyond my ken.

QOD - Situational Piety

"On land I worship Christ, but at sea I worship Thor."
Helgi the Lean, early Icelandic settler

Obamacare Rules! (?)

A CNN exit poll on Tuesday asked the following question:

What Should Congress Do With New Health Care Law?

Results:

31% Expand It
16% Leave It As Is
48% Repeal It

Yeah, Americans hate Obamacare so much that as many people LIKE the healthcare bill as those oppose it and a third want more of it.

COBOL Rules!

Having taken a position with a firm that recently launched an Agile Development initiative, I have been giving a lot of thought to how software is developed.

First off, I will say that I don't hold out much hope for Agile. Every company has its own work culture which is entrenched and not easily shifted. Some may be ripe for accepting an approach like Agile Development but most are not. If Agile is launched an AVP with a memo and training program, just sit through the seminar and wait. It will go away just like Who Moved My Cheese.

More generally, I think we spend much too much time and effort in agonizing over organization and methods instead of producing quality programs. I don't mean we need test-driven development or a million test cases in the QA group. I mean that little attention is paid to the actual code that is produced. Is it efficient? Is it secure? Is it robust? Is it easy to understand and modify? I believe W Edward Deming said that the problem with management is that it reads too many management books and not enough statistics. Same with programmers. My last organization did a Lunch-and-Learn series on best practices in coding specific situations. It was nice. Most of what I see, though, is google-the-problem/copy-a-sample-from-a-blog/compile-the-result. And that is when they aren't trying to stay on the bleeding edge.

I have rediscovered an admiration for COBOL programmers. I have to assume that the senseless dash toward "progress" seen in Java programming circles is less an issue in COBOL, which is considered a dying computer language. These guys and gals receive a request or specification and then code a solution. End of story. No need to impress anyone with the latest framework, there.

I read a comment thread recently which mentioned the "80% of anything is crap" rule with regard to programmers. Why don't we attack this statistic by attempting to make that crap a little less aromatic? What we need is a movement to improve the quality of programming by teaching theory and best practices. We all know that well written code is less prone to errors. But do we pay any attention to coding? No! We spend most of our time talking about patterns and pair-programming. Perhaps with enough theory and programming philosophy, developers might recognize that moving something from the Java source file to an XML file does not reduce the code, it merely translates it into XML. Or that using JUnit increases your code-base because your test modules are programs too that may need to be tested themselves.

I have been a programmer my entire working life but I trained as an engineer. I often wonder when will the time come when software "engineering" lives up to its name and drops the hacker culture and becomes a true discipline.

Code Smell

Can I count any Java class with the string "Util" in its name as smelly code? Helper classes, utility classes, they all scream. "I am Not Writing Object Oriented Code!"

Speaking of Protocol Droids ...

In my previous post, I might have inferred that protocol droids are annoying. If that is the case, then: Good. That is what I meant .

In reflecting on this further I remembered a train of thought shared back in the misty past of this blog: is it possible to create artificial intelligence without designing in some level of artificial neurosis.
I realize that C3PO's function in Star Wars is as comic relief. His quirky personality might be further justified by the fact that he is indeed a homemade droid built by Anakin Skywalker (in the heretical Episode 2 - or was it Episode 1 - who cares!) . I choose to think that C3PO's sometimes role go between for machines and people has required that he be designed to understand the weird thought processes of the human side of this transaction.

To be sure, C1PO was quite conversant in the binary language of moisture evaporators. Yet his designers (C# programmers no doubt) foolishly assumed that human communication could be achieved following the same simplistic assumptions required to understanding the ramblings of Obi Wan's toaster.

C2PO proved completely inadequate to deal with even the sarcastic utterances of an R2 unit. Only when the development team (having ditched Agile Droid Development in favor of actual forethought) watched the home movies of Anakin hiding his Halloween candy from Leia did they fully appreciate the possibilities of cyber-paranoia.

I Need a Protocol Droid

"What I really need is a droid who understands the binary language of moisture evaporators." - Uncle Owen (Star Wars - The Real Movie)

Working in software development, I am continually inflicted with the latest open source scheme to transform the way we program computers. Someone in the organization decides that WidgetScam 2.1 will make waterfall, procedural, proprietary coding a thing of the past.

First off, there is some resume padding going on - software architects recommend to management the latest thing so that they can put it on their resume inspite of the fact that it will make the comopany no more productive or profitable. Relatedly, I believe that there is an ego factor whereby individual programmers need to feel like they are on the cutting edge. Me, I am old fashioned. I take pride in being a pretty good debugger and in being able to produce decent code that solves the needs of the customer (remember them?)

One amusing thing about this technological arms race is that we install all the new jars and dlls on our laptops and then keep programming the way we always have. Don't get me wong. I like programming in Java. It has some nice properties but Object Oriented Programming was sold as a complete paradigm shift in IT. Have you looked at any Java code recently? Most of it is dressed up C. Most programmers are writing procedural code in .java files. Of course, it works. It does what the specs require (most of the time) but there is no way that the advertised benefits of OO are going to realized.

So where are we now. I spend my days trying to install (and re-install, and re-re-install) software development tools on my cutting edge laptop all the while trying to balance my 64-bit vs 32-bit apps, the programs that require Java 1.5 vs those on 1.6 and the three different document repositories our company is using (Wiki vs network drive vs Alfresco). My industry is approaching the point where two systems will not be able to share information without an intervening layer that is more expensive, cumbersome and annoying than a protocol droid. Sometimes I wish we all just had R2 units. They aren't real shiny but they seem to get the job done.