Tuesday, September 18, 2012

The Meeting is Almost Unnecessary

A few of you have noticed (and I guess that is a good thing) that I haven’t posted a blog entry recently. I just returned from a few continuous weeks of vacation. I try to lump my time off together to really decompress from the normal business cycles. Right before vacation, I’m not fun to be around.

It’s pretty easy to tell when I’m nearing my self-imposed banishment from architecture governance as I get this kind of pre-vacation glow about me. Bread goes stale faster, sunscreen loses its effectiveness, and paper appears to spontaneously combust. I’m not fun to be around.

Vacation planning for me starts with a reading list, a few household projects calling my name, and the mad dash to get all of my work assigned to the poor suckers that are doomed to work with me.

Did I mention I’m not fun to be around?

While the preparation for the vacation is vitally important, it does not in and of itself provide the relaxation, serenity, or home improvement that results from actually not coming in to the office. In that regard, vacations are not like an Architecture Review Board meeting.

Over the course of ten years, I have found that preparing for an ARB is often more valuable than the meeting itself. The effort and work products required to engage in a meaningful architecture conversation often resolves long standing issues, or brings the very clarity of direction sought in ARB meetings.

This is not an accident. The ARB purposefully establishes a number of required artifacts for the express purpose of ending ambiguity and establishing a practical, positive path forward. You simply cannot achieve that in a one-hour meeting.

Again, I have just returned from a multi-week vacation and feel great. You may find me whistling in the hallways, wearing a quickly fading tan, and hear me discussing my two newly painted bedrooms with far more glee than is tolerable.

I am looking forward the ARB’s this summer with renewed vigor and excitement. I may actually be fun to be around.

Sunday, June 17, 2012

Milkmen, Fathers, Architecure

"Joanne read in a magazine that a milk bath does wonders for your skin. So she wrote a note asking the milkman to leave 100 bottles of milk for her next delivery. Carl, the milkman, saw the note, and thought there must be an error in the number of zeros. He knocked on the door and asked Joanne, to clarify the order. Joanne confirmed that she wants 100 bottles to fill her bath. The milkman then asked, 'Do you want it pasteurized' Joanne replied 'No, just up to my neck'."

Jokes about Milkmen have been around forever, even if the practice of home delivery has been dying off.

I don't ever think my family used a milk delivery service, and as the picture here will demonstrate, I look just like my father thank you very much. After a peak in the early 1960s, the home milk delivery business plummeted until about 2000, and then started to pick up again. Mostly, it is estimated, that the combination of convenience for two-income families and the desire for fresh local milk has spawned a re-emergence of this industry.

There are only a few key elements to milk delivery business. Get them right - you stay alive. Get them wrong, hello Monster.com. Customers of home milk delivery want convenience and reliability. Frankly, they can buy milk just as good from the local grocer - and for less money. Everything you do, must be focused on convenience and reliability. Period. As Dad might say, nothing else matters.

If you were an Enterprise Architect in a milk delivery company you'd design systems to maintain the tenuous just-in-time stream of fresh milk from local suppliers, schedule drivers, configure delivery routes, drive down costs, maintain infrastructure, lease vehicles, manage inspections and repairs, and of course, conform to regulations.

Imagine pitching a new GPS tracking system to improve on-time delivery and enable real-time tracking of milkmen. For the first time ever you would be able to monitor milkmen who stay suspiciously long at certain addresses! Snicker, snicker.

If you think you want the new cool GPS, you have to equate it to convenience and reliability. I don't mean you have to find a way to cleverly convince your boss that a GPS will improve reliability - you have to be able to prove it to yourself; and you should be a skeptic.

As technologists, we can be overly enamored with the prospect of adding new solutions, tools, and capabilities to our arsenal.

Architects must understand the key drivers of our businesses and skeptically evaluate every solution in terms of it's impact on those key drivers. Are you concerned that your company doesn't have the latest technology? If you can't prove a need, then spend your intellectual energies on improving your use of existing technologies.

Here's a test -- whatever the cost of your next project, assume it is the last 'N' dollars you have for the next two years. What project would you spend it on? Before you implement that SOA solution, the latest JDK, the newest database engine, or a cool new network appliance, prove there is no better way to invest the money.

Sunday, June 3, 2012

Why Fixing Cars is Not Fun

As objectively reported here on a number of occasions, I am a mild mannered enterprise architect who often finds himself sucked into a cesspool of insanity and illogic. I don’t go looking for arguments, confrontation, and ambiguity, but somehow they find me and like dental tools, pick and jab at the softened nerves of my tolerance.

I currently own a 2008 Saturn Vue. It is the 11th consecutive Saturn vehicle I have owned since 1993. When I bought my first one, a used 1991 Saturn SL1 stick shift I found a car, a dealer, and a relationship that I could understand. My wife and I then returned to the dealer every few years to update one of our cars - always to a current-year Saturn.

Well, that’s not going to happen again, since the restructuring of GM resulted in the entire Saturn program being shuttered. As it turns out, that is not the insanity that caused this post. No, this special little gem of cranial shock came from having to change a headlight.

With the demise of the dealership, I have found myself returning to a world where I attempt minor car repairs on my own. Did I mention that I am a mild mannered enterprise architect? Well, not when I’m working on cars. Since the age of 12, I have yet to pop the hood and not utter elongated strands of inappropriate epithets directed at the designers of automobiles.

My brother claims to repair cars as a hobby; for fun. How can this be fun? By what definition is locating and removing three screws that cannot be seen, felt, or reached by any tool that conforms to the rules of algebra be fun? I know fun. Fun has an element of “I would do this again.” This is not fun!

Switching a headlamp on a well-designed, well-maintained, highly-rated, consumer-friendly mature SUV should not require an advanced degree, super special tools, or a secret handshake.

Apparently, however, all three are assumed.

Look, headlights wear out. They will have to be replaced. This is not a dispute, it is inevitable. Therefore, a sane person would design the housing of the headlights so that the lamps could be easily replaced. Additionally, any necessary documentation for said lamp change would be readily discoverable at the time of need.

A week ago, I literally replaced the tail light on my son’s Ford Focus in 15 minutes with no tools. Some human-ish being thought through the inevitable replacement process and designed a reasonable structure (one might call that an architecture). In other words, my request that common events should have well-planned responses is actually possible.

As architects (we are all architects), our solutions have to include in the requirements, “what is likely and / or inevitable” and build our solutions around actions that embrace reality. My reality is that I have to look for a new car, ‘cause fixing things designed by cruel psychopaths challenges my mild mannered demeanor.

Thursday, May 24, 2012

Architecture and a Boy Named Sue

My Daddy left home when I was three,
He didn't leave much, my ma and me,
This old guitar and an empty bottle of booze.

Now I don't blame him 'cause he run and hid,
But the meanest thing that he ever did,
is before he left,
he went and named me Sue.
- Johnny Cash

I'm going to guess that Johnny Cash's metaphorical father was an Architect as he understood the critical role a name plays in the life of a person (or a song, a function, or anything).

I return again to the topic of naming, and how a name is the single most important element of understanding you ascribe to anything you create. For this post, I'll focus on the names we give our projects.

We recently engaged Gartner for direction and counsel on a number of topics and one of their pieces of wisdom was that we should take more care in the names our business-aligned technology teams (MIS) give their projects. This is excellent advice!

We are constantly challenged to demonstrate the value that IT provides to the business. This is not a flaw in the system, as business needs to- and should challenge all aspects of their operations to ensure they are getting adequate value from all of the resources.

But we have a tendency to name our projects according to the importance the projects has to us, rather than our customers. This is a missed opportunity. Consider these IT project names:

  1. EOL Server Refresh
  2. XYZ Baseline Support
  3. Resource Availability Computation
  4. Transaction Management Phase II

Trust me, I've seen worse. I’ve seen project names so obtuse, that even with a 255 character description field I still couldn’t figure out what it was. How about "Exacerbate malevolence retrieval" - a project to implement predictive caching, or as the customer would understand it, "Improve Application Speed by Anticipating User Selections."

The four projects above could be better named as follows:

  1. Update Aging Servers with High Speed & Capacity Replacements
  2. Rapid Response & Preventative Maintenance of Customer Reporting Application
  3. Create Instance Product Availability Graph
  4. Priority Transaction Management Features and Functions for 2012

Take a look at your list of project names and begin to think about this coming budget season. How can you improve the names of your project for next season so that your customers can more easily see the value you provide?

Saturday, May 19, 2012

Deliberate Practice and the Art of Enterprise Architecture.

I'm a mild mannered Enterprise Architect that was recently asked to speak at an industry conference on any topic I wanted. I thought the conference organizers were nuts (or they didn't know me very well.)

I any event, I chose the following topic.

Sunday, May 6, 2012

So what do you do? (tick, tick, tick...)

I had the opportunity last week to speak at a Forrester Conference on the topic of Deliberate Practice. I’ve written about this before, but wanted to focus on one particular opportunity we all have.

The picture to the left is of Santonio Holmes, a wide receiver who played for the Pittsburgh Steelers in Super Bowl XLIII (43). This shows his winning, come from behind, touchdown catch with less than 40 seconds to play.

The picture begs two important questions:

  • How many opportunities does an NFL wide receiver have to catch a winning, come from behind touchdown, with less than a minute to play, in the most important game of the season - in their entire career?
  • How often do you think they practice for this play?

Most wide receivers will never get the chance, yet they practice for this opportunity all the time.

Well, we’re not wide receivers, and our success has little to do with catching footballs, but here is an analogy that fits well. How often do we practice our elevator speech? This is the speech, or answer that we’d give if we found ourselves caught on an elevator with our CEO who has just asked, “So what do you do?”

Our answer must:

  • Be short, yet clear
  • Contain no jargon, technical language, or inside-meanings
  • Express a value the receiver will appreciate
  • Have no assumptions as to context

This is as hard as running at a dead sprint to the corner of the football field, leaping into the air, landing with both feet in bounds, while maintaining control of the ball.

You may wonder how many times you’ll need this answer and whether or not it is worth it to have something prepared. Seriously? Would you want to risk having 30 seconds with your CEO, Chairman, or a dozen other high-profile executives in the company, who happen to ask what you do, and you have to be extemporaneously clear, clever, and concise?

Having prepared a short (20-30 seconds) response also helps you define for yourself the value you bring to the organization (which could be useful next February, if you catch my drift!!).

Thomas Jefferson once remarked that he was going to write a long letter because he didn’t have time to write a short one. Your elevator pitch will take time, and you will likely fail miserably on the first five tries. You will have implicit assumptions about your department, or you’ll use what you think is common terminology, or you’ll focus too narrowly on scope.

Write it down. Edit it. Set it aside. Try again tomorrow. Try it out on people who have no idea what you do. If they nod politely, you failed. Try again. The co-worker in the next cube is of no help, they know too much detail. Don’t “dumb it down” rather, abstract it up.

In your entire life you may only get one opportunity to win, coming from behind, with seconds to play. Be prepared. Practice this deliberately.

Friday, April 20, 2012

Humans Just Don't Do That Very Well


Dateline: 1988, somewhere around the planet Mars.  Russian Mars probe, Phobos 1, was ordered to commit suicide by a ground-based human controller who sent it the wrong commands which were meant to slightly adjust its trajectory. Control of the spacecraft was transferred shortly before the disaster to a new command center, and one consequence of the transfer was that commands to the probe had to be entered via very long strings of characters; in this case several pages long.

The typist only had to create a perfect three-page document. Humans don’t do that very well.

Dateline: 1995, Pittsburgh High Occupancy Vehicle Lanes.  Six people were killed when an employee incorrectly switched the access gates on the single-direction HOV lanes.  Pittsburgh's "Parkway North" has an HOV lane that feeds inbound in the morning and outbound in the afternoon.  Gates are used to restrict the flow of traffic. An employee responsible for switching the gates mid-day, incorrectly opened the outbound gate before closing the inbound gate, thus creating a scenario where high speed traffic was entering from both directions.

The employee only had to execute the correct sequence. Humans don’t do that very well.

Dateline: Yesterday, my home, south of Pittsburgh. I approached the light panel in my foyer which contains three switches; one for the hall, one for the top of the stairs, and one for the porch light. I know I will get this wrong as I have never hit the correct switch for the desired light in three years.

I am human. I just don't do that very well.

Dr. Marc Green, a Human Factors author writes that up to 90% of all errors are attributed to humans, and that conventional wisdom asserts that the cause of human errors are lapses in judgement, inattention, or carelessness.

But the research shows, quite clearly, that humans are built for (by design or evolution) variability. We are genetically encoded not to perform repetitive, mundane tasks in the exact same way each time, ie we are not reliable in these contexts.  In fact, we are not capable of rote repetition, or precise sequences.

As architects (we are all architects) we must design solutions that embrace this essence of our humanity. If a mistake can be made by a person, it will be; and appropriate controls must be instituted for guidance and remediation. A fundamental construct of system design is that every destructive action must be undo-able, or require non-perfunctory validation of execution.

It is not human stupidity, boredom, or carelessness that causes errors, it is that we are probabilistic rather than deterministic in our nature - that which allows our adaptability to the new and novel prohibits our enslavement to the repetitive and mundane.

Sunday, March 25, 2012

How Do You Screw Up a Two-Button Machine?

I had the occasion to visit the Department of Motor Vehicles last week to update my drivers license with a new photo and a change of address. I entered the lobby area where there was a short line leading to a "Take a Ticket" machine. How hard could this be?

Curiously, it was taking some time for the customers to "take their tickets," leading me to ponder the average level of intellect found in the general populous of roadway cohabitors.

Turns out that the DMV has three service counters depending on why you’re there and a different turn-counter, thus a need for three different "Take a Ticket" selections. You don’t just take a ticket, first you have to determine which service you want and then take the appropriate ticket to get into the appropriate abuse line.

But wait, the DMV has automated the "Take the Right Ticket" process with a handy-dandy three button ticket dispenser. What could possibly go wrong?

One button was labeled "Driver’s Examinations," and I knew that wasn’t the button for me.

The two remaining buttons read, "License processing" and "Photo processing." Pick one. But, but, but .. I need (I think) a little of both. Suddenly my earlier thoughts of despair over the intellectual inadequacies of indigenous drivers were replaced with utter contempt for the person or persons who designed (essentially) a binary selection so ambiguous as to cause brain spasms.

I actually touched my temple with the heel of my hand and moaned, "Whoever you are, you are evil." HOW DO YOU SCREW UP A TWO-BUTTON MACHINE?

I tried to get inside the mind of the designer, to think as they would think, to select the button that would get me to the correct line of perpetuity. As I recursively looped through the permutations I felt a gentle tap on my shoulder. "Dude, it’s just a ticket machine - take a ticket and move on." I now hate two people at the DMV.

I pushed the most logical button, grabbed my ticket and proceeded to the wait line. I eventually discovered, that I needed to be in the other line.

The point is that the creator of that three-button ticket machine knew the right ways to interpret the questions to yield the correct selection, but failed to consider the view of a person who is not an expert in the inner workings of the DMV. This falls into the "customers-have-to-know-how-we-work-to-use-our-services" model. This is a failed strategy.

It’s not easy, but we must strive to continually think as our customers think, rather than how we wish they think. That our customers may be fellow employees does not reduce our responsibilities.

Sunday, March 18, 2012

Are You Ready for April 1?

April Fools day has been celebrated as far back as 1632, if you believe in Chaucer’s Canterbury Tales and bad math, or possibly as far back as 500 BC (if you are of Iranian descent). Regardless, it is a day to approach with some wariness if you are not a practical joker, and with evil excitement if you are.

In 1962 the one and only Swedish television station announced that its viewers could watch their broadcasts in color, if they merely covered their television screens with ladies nylons. Apparently Swedish women had very large legs.

In 1998, a newsletter, New Mexicans for Science and Reason, stated that a state legislature was proposing to change the value of PI from (approximately) 3.14 to its proper value of 3.0. They were confusing the relationship between the circumference of a circle with its diameter and the first version of any Microsoft product that actually works.

April Fools Day of 1976 saw BBC Radio deliver a message from astronomer Patrick Moore that a once in a generation event will cause all of the planets from Mercury to Pluto to be aligned causing gravitational distortion on Earth. People would actually notice the phenomenon if, at precisely 9:47 they would jump into the air. We know this to be false because Pluto is not actually a planet.

In our profession we come across April Fools jokes all the time, we call them Vendor Solutions. Like most good jokes, these have just enough truth in them to be believable. Have you heard about the one that combines hardware, operating systems, and application software all together in a single appliance that promises untold performance, ease of use, security, and doubles as a floor wax? (OK, I made up "ease of use").

In 1976, the planets did align and there was some theoretical manifestation of anomalous gravitational effect - completely undetectable by anyone not descending in the elevators of the USX Tower at exactly 9:47. Again, a grain of truth mired in obfuscated knowledge, marketing-speak, and PowerPoint slides.

Don’t get me wrong, our vendors provide valuable products and services to our industry beyond golf outings, sports tickets, and great stories. But like any good steward of corporate resources, we should trust but verify everything they say. This means, asking tough questions; like "You say your solution will scale to support our data even though you have no other clients this size. Prove it."

In this context, "prove it" doesn’t mean show me a presentation; it means (to the vendor) create a situation where we can verify the input data, the output results, and the throughput performance. The words, "Trust us" are not proof.

Do not be the victim of an April Fools joke - at any point during the year. Our vendors are here to support us; we are the customer and have every right to require proof of performance, of quality, and of value.

Friday, March 2, 2012

Does Architecture Put the No in Innovation?

I cannot hide my love for gadgetry, technical wizardry, or miniaturized electronics. I still have an Apple Newton, a Palm Pilot, and even a Rex PC - a PDA so small (think business card size) it slid into the PCMCIA slot in the side of your other PDAs and synchronized with your email, calendar, and task list. The Rex PC was just one dangley thread on the wool suit of emerging technology, circa 2000.

While a lover of technology in general, I am not particularly fond of the rapid rate of change. As soon as I get a new toy productivity solution home, it begins the rapid decline into humor fodder - resulting in an inability to integrate, synchronize, or upgrade, thus rendering my once-impressive array of techno-hipsterness into a hidden collection of useless digital dust collectors.

I still hold out hope that during some unimaginable disaster, I alone will have the one combination of elderWare that will save mankind, not unlike the invisible bacteria that saved Earth in "War of the Worlds."

Innovation. I just love the new and novel, which might mean my current role of Enterprise Architect is somewhat of an apparent contradiction. After all, doesn't my job make me the Sargent of Arms for corporate standards? Don’t I speak Innovatum-non-grata from the Holy Book of Principles and Practices. Am I not responsible to ensure we always reuse the infrastructure, compenentry, and assets into which we have poured untold dollars, time, and careers? Do I not put the No in Innovation?

The truth be told, I happen to believe that standards and innovation go hand an hand. Standards, operating practices, Business Accelerators, and common reusable assets foster, rather than inhibit, innovation.

Consider northern Nigeria in the late 1990's. The lack of suitable refrigeration literally killed people and destroyed opportunities for social and economic progress. Mohammed Bah Abba, a business man and college lecturer used a combination of two clay pots, one inside the other, separated by wet river sand to create a cooler. As moisture in the gap evaporates from the outer pot towards the dry desert air, the temperature in the inner pot decreases.

His solution, while highly innovative, used the resources that were readily available.

Standards, assets, and practices can be thought of as structures that facilitate the expression of creativity. Think of your favorite song or musical genre. Take a moment and ponder your music library, your iPod, or your albums. Even though music is bound by a finite number of notes, chords, keys, and of course the notion of rhythm, it is still considered a boundless avenue for creativity.

Standards are not an obstacle to innovation; standards, structure, shared assets - these are the facilitators of innovation!

Thursday, February 16, 2012

Practice Perfect Driving

I remember very clearly the day I taught my kids to swear. Oh, this was no well thought out exercise based on principles like expanding my child’s world view in a carefully controlled environment. Nope this was, Oh SSSHHHHOOOOOOT ..... (or something close to that).

In my defense, this started out as a good idea. Really - stay with me. Each year after the Winter’s first snow fall, I take the car up to the High School parking lot and reacquaint myself with treacherous driving conditions. I purposefully lock the tires, yank the steering column and such to put the car into an "uncontrolled" condition.

I then, deftly, regain control. This is called "Deliberate Practice" and is intended to make sure that if I ever need this skill, it is available as almost instinct.

Being short on time, I decided to do my annual practice en-route to the store with my kids in the back seat. Everything was going well, and the kids were actually enjoying the experience as well as the witty banter emanating from the driver’s seat.

I hit a patch of black ice, and the previously controlled, now uncontrolled Saturn Vue turned into a 2,000 pound bumper car. I am convinced that even the most gentile of us has a curse instinct that flows freely under perfect conditions. Uncontrolled car; helpless kids; rapidly approaching telephone pole - Perfect.

At the last minute, the front wheels did find traction, and I pulled out of the slide safely. Nonetheless, my children were introduced to at least one string of colorful metaphors.

Deliberate practice is the task of preparing for your work, that does not include your work. It is not merely enough to say, "I’ve been a developer for ten years, therefore I’m ten years better than I was." In fact, you may actually be worse as a result of only being required to execute a narrow set of skills.

When you consider that the human tendency is to gravitate towards that which comes easy to us, then it follows that activity inertia and free choice tend to cause us to reuse the same set of skills again and again. If you have a really good hammer, nails abound!

Most of us drive the same car, over the same roads, at the same times of day again and again. Same with work. We focus on a narrow set of problems with a narrow set of tools in a narrow business context.

To stay sharp in our craft, we need to Deliberately Practice the skills we may or may not be using each day. Yes, this means configuring servers in ways outside our normal context, or learning a programming language we don’t need right now. This could mean reading a book (with practice exercises) on architecture.

Deliberate Practice is not easy, and is not meant to be. It is meant to expand your capabilities, keep you sharp, and make you more valuable.

Friday, February 3, 2012

Gaming the Hire Process

Allow me to apologize for the length of this narrative as I need to provide a direct quote before launching into the actual subject. Imagine a universe in which video games were invented before books. Because books would come later (i.e they would be a new medium) they would be assailed. You could imagine that a critic of books might write:

Reading books chronically under-stimulates the senses. Unlike the longstanding tradition of game-playing - which engages the child in a vivid three-dimensional world filled with moving images and musical soundscapes, navigated and controlled with complex muscular movements - books are simply a barren string of words on the page. Only a small portion of the brain is devoted to processing written language which is activated during reading, while games engage the full range of the sensory and motor cortices.


Books are also tragically isolating. While games have for many years engaged the young in complex social relationships with their peers, building and exploring worlds together, books force the child to sequester him or herself in a quiet space, shut off from interaction with other children.


But perhaps the most dangerous property of books is that they follow a fixed linear path. You can't control their narrative in any fashion - you simply sit back and have the story dictated to you. Why would anyone want to embark on an adventure utterly choreographed by another person.


Reading is not an active, participatory process; it's a submissive one. The book readers of the younger generation are learning to "follow the plot" instead of learning to lead.

That is an excerpt from the book (how ironic) "Everything Bad is Good For You" by Steven Johnson which takes a humorous but legitimate look at the notion that pop culture is all bad. Current video games engage the brain on many levels, requires coordinated group participation, and lots of learning by extrapolation.

According to the Entertainment Software Association 65% of American households play some form of video games, the average age of a player is 35 and has been playing for 13 years. Keep that in mind - the average gamer has been at it for over a decade. In 13 years of college you could have two separate four-year Bachelor's degrees, a masters, and a PHD.

The next time you are interviewing a candidate for a job opening, ask if they play any video games. For if they do, here are some of the skills they have built up during their "off hours."
  • Problem solving - Most games begin with a few base assumptions and a specific goal (save the queen, acquire wealth, destroy the aliens, ...) but not much else. The player must figure out from context cues, trial and error, and experience how to navigate, analyze threats and opportunities to achieve stated or self-determine goals.
  • Patience - Modern games take a long time to play. A game of Monopoly might take 4 hours. Today's video games require four hours to get familiar with the keyboard.
  • Accepting setbacks - No one, and I mean no one, traverses a video game without failure. Most gamers never achieve the final victory and yet they persevere night after night, trying one dead-end path after another, learning, become more skillful, gaining more ground. Adversity just doesn't have the negative impact it did on earlier generations.
  • Teamwork - The notion that game playing is a solitary activity negates the presence of thousands of on-line forums, social circles, and of course on-line interactions during game playing. True, some games can be enjoyed alone, but even some of those involve social interactions between the actors.
  • Leadership - Multiplayer games often involve leadership roles which change from person to person as the game activity changes. Players are respected for whatever role they play as all are needed for success.
This barely scratches the surface of gamer value. IBM published research about gamers and Leadership in Games and at Work and found that while there some differences in which skills are most valued, all of the skills needed for effective leadership are present in Multiplayer Role Playing games.

Harvard Business Publishing, a wholly-owned subsidiary of Harvard University, recently said gamers are bottom-line oriented, understand the power of diversity, thrive on change, and see learning as fun.

If you are in a position to hire, look with glee upon the candidates who openly express their prowess on the console. They may not have the best tan, but they very well may have an exceptional mind.

Thursday, January 26, 2012

The 10,000 Hour Rule

What is the secret to being really good. What makes a good Programmer, Business Analyst, Admin, or Architect? Does it require superb instruction, years of isolation, physical prowess, intellectual giftedness, and a burning desire emanating from a childhood trauma? I suppose if you aspire to be Batman and you live in a fantasy world that includes talking penguins, then that combination of ingredients will yield a terrific defender of truth, justice, and the American Way. Or did I subtly shift super hero genres?

I grew up at a time when The Beatles were all the rage. The songs of the four mop tops once held all five top positions on the music charts at the same time. Among other things history shows us - these guys were excellent musicians (OK, maybe Ringo was average).

Us I.T. folks can learn from The Beatles, because as it turns out, they had a lot of practice before they hit it big. We know, (again from the historical record), that the Beatles had over 10,000 hours of practice/performance time in - before they were stars.

A 1990’s era study by Berlin’s Academy of Music provides us with a similar lesson. Adult students were divided into three groups. The first, the "stars" had demonstrable talent - they were the gifted ones. The second group of musicians were good, but did not show the same level of promise as the first group. The third group, based on their ability, would likely never play professionally.

All three groups were asked a series of questions to determine how much time they practiced. All three groups of students began taking music lessons around the age of five, and practised two to three hours per week. Around the age of eight, the students who would later be identified as great, upped their practice time to six hours a week, increasing to 16 hours per week by age fourteen. By twenty, the "gifted ones" were practicing with purpose (not just going through the motions) 30 hours per week. Added up, these musicians, the "gifted" ones, had logged more than 10,000 hours of practice time.

Turns out, the 10,000 hour rule is pretty standard; across disciplines, fields of study, arts, crafts, medicine, and even computer technology. It matters less what you were born with, and more how much you dedicate yourself to the task. By the way, 10,000 hours of doing doesn’t count. Doing is different than practicing.

Think of any endeavor you admire; football players, surgeons, pilots, singers, even project managers. The good ones don’t just do, they practice. They read about, they write about, they handle artifacts, they discuss stuff, they try new things related to their discipline. They practice their craft all the time.

So... how good do you want to be?

The point is simple; the more you practice, the better you’ll get.

Thursday, January 19, 2012

What's in Your Backpack?

The movie "Up in the Air" stars George Clooney, who plays the part of a professional "Displacement Manager", i.e. he is hired to fire people - and he's very good at it. Clooney's character also has a side-job - as the world's worst motivational speaker. How he ever lands an engagement is one of those Hollywood riddles that you just have to accept. Kind of like the last Star Trek movie when young Kirk is marooned on an alien world which is close enough to witness the total destruction of a neighboring planet, but somehow is unaffected by the obvious gravitational distortion. Yeah, like that.

In "Up in the Air", Clooney's alter-ego uses a backpack as a metaphor for all of the things in your life that are holding you back. He suggests friends, relatives, spouses, co-workers, and such are the things you throw in your backpack that just weigh you down, hold you back, make you unsuccessful. (This is his "motivational" message!).

George, if I’m ever depressed, please just leave me alone.

Clooney's motivational lack of elegance notwithstanding, the backpack metaphor can be applied to our work in I.T. Every project comes with certain challenges such as costs or time lines that causes us to forgo perfection. We learn to accept (create?) poor quality documentation, obfuscated APIs, fragile connections, magic numbers, and stupid coding tricks just to make our time / cost estimates.

These get thrown into our support backpack. They weigh us down, reduce our satisfaction and infuse errors and performance problems into our systems. This baggage holds us back, keeping us tied to systems from which we'd like to progress away. This year, find something in your backpack to get rid of. This might mean revisiting an existing solution on the down low and replacing a “hack” with a “hooray!”

Maybe you can lighten your backpack by committing to never using a magic number in your code. For instance:

for( int x = 0; x<=9; x++ ) {
// some code
}

In this instance, '9' is a magic number. Why 9? Why not 8 or 10? Yes, yes, I get it, you want to loop 10 times, but why? How about:

static int MAX_ALLOWABLE_ACCOUNTS = 10;

for( int x = 0; x < MAX_ALLOWABLE_ACCOUNTS; x++ ) {
// Some code
}

The next developer to touch this code (assuming an IQ over 12) is at the very least going to ask, "Why do we only allow 10 accounts?" This becomes a business question that will yield a better understanding of both the business model, the program code, as well as a lighter backpack for both you and the next coder.

This change takes no additional time, costs zero additional dollars, improves the understanding of the business, reduces future maintenance time, and lightens the backpack for everybody. If that isn't motivation enough, maybe we could arrange a one-on-one with George Clooney.

Thursday, January 5, 2012

Use Stage Gates to Manage Project Progress

Reading a map is a lost art I suppose, but whether you're used to MapQuest, Google, Garmin, TomTom, or plain old Rand McNally, one thing is for certain. Most people consult their maps multiple times en-route to a new destination.

If you've gone astray, you figure out how to get back on path. If you've strayed too far, you might even decide to scrap the trip, start over, or select a new destination. In the vernacular of Architecture, this is called stage gate risk mitigation.

Here's some delightful industry news, the 2009 version of the Standish Chaos report indicates that only 32% of I.T. projects are delivered on time, on budget, with required features and functions. 24% of all I.T. projects fail, i.e. are cancelled prior to completion and never used.

We should probably stop denigrating weather forecasters.

One of my older sisters is very bright, being the only doctor in the family, she has had to demonstrate her brain power to excel in her chosen field. But give her a map to read and she becomes the driving combination of Helen Keller and Dick Van Dyke. Simple things like, "Sis, start with placing the map in front of you with the north end of the map towards the top." "But, " she says, "what if I'm not going north." "If I turn the map as I'm driving, doesn't that send me in the wrong direction?"

"Why yes Sis, If you turn the map, the whole globe shifts." /s

An organization that identifies itself as a leader in managing risk, should approach I.T. projects with a stage gate philosophy. Approvals to move forward should never be a binary manager-take-all go/no-go decision. Rather, approvals should be based upon current state, predictability of the next steps, and a continued re-examination of return on investment.

A stage gate approach provides for a natural re-evaluation of the architecture of the system. If we rely on common sense, intuition, education, and best practices when taking a road trip, then we should adopt as Standard Operating Practice the process of stage gating our I.T. projects.

The Architecture Review process should use a stage-gate approach to ensure that technology directions are sound, and that they stay sound as projects unfold. There’s nothing wrong with changing directions (detours happen!), but deviations from the plan should make just as much sense as the original plan.

Follow by Email