Shifting Gears

Anyone who has ever chugged along trying to their teenage child how to drive a stick (manual transmission) can appreciate the complexity of the task. No doubt It is more complicated to teach a teenager (or anyone) how to drive a manual transmission than an automatic transmission. The reason being is in an automatic transmission much of the complexity of driving has been hidden away and is not seen by the driver.

The complexity was not just hidden it was transferred. It was transferred from the driver to the transmission because an automatic transmission is more complex than a manual transmission. An automatic transmission is more complex (and expensive) to design, build, and maintain too. As software development matures we see much of the complexity being hidden from users. As an example, look at the complexity of booking a hotel reservation or airline reservation. Most of the complexity of has been nicely tucked away.  It cost a ton of money to hide all that complexity and functionality.   Once upon a time it took a trained travel agent to book an airline flight. Nowadays just about anyone can accomplish this task.

My teenage daughter drove to school today chugging and grinding the gears.  In due time she will learn to drive a stick shift.  The same is true with software development.  We are chugging along and grinding the gears trying to transition from internal applications (exposed complexity) to customer self service (hidden complexity)


Agile Coach — WTF mate?

Like a lot of people I put my resume on job sites.  Yesterday I was sent an automated human resources message.  It read, “A job opening matching your profile for a position of Sr Principal Agile Coach has just been posted in our Career Section.” There is nothing in my resume that shows an interest in becoming an Agile.   I thought well, perhaps, the human resource bot searched the internet and got a lot hits on David Longstreet and Agile (there are over 500).   Perhaps it was my article, “Agile Methods and Other Fairy Tales” that got the bots attention.

Perhaps it was the fact that those professionals in Agile wrote that I was a troll or “a so called international consultant.”  As an FYI, when anyone starts a sentence with “a so called…” what follows is not going to be a complement.

I decided to apply for the position to see what happens and I will keep you all informed.

For those who want to read my ideas on Agile (and for those HR bots) you can see them at

Cooking and Communication

This past weekend I tried a new recipe that turned out brilliant. I can’t take too much credit because I followed a recipe provided by America’s Test Kitchen. There are a lot of analogies between cooking and developing software. Not all recipes are created equal and some are better written than others. The same is true of documentation. The point of cookbooks and cooking shows is to communicate a process to another person. This is also the reason behind documentation. In other words, documentation is an attempt to communicate a process to another person.

I like America’s Test Kitchen because it provides videos with detail explanations of the science of cooking and written recipes. Not only do they provide a detail explanation of how to prepare the dish in both written and video formats, they also explain the science of cooking. On the other extreme is learning to cook by trial and error. Learning to develop software by trial and error seems to be the norm rather than the exception in software development.

Many of us learned to cook from our grandmothers by verbal instruction. My grandma left off steps or failed to emphasis a specific point (she would tell you that I was not paying attention). If grandma was in a hurry she was terse in her explanations. This is the same problem when verbally explaining how a software process should work. Experts often leave off important steps or fail to emphasis a specific point. They often blame the user for failing to understand too.  Another excuse is not having time to communicate and this can be overcome too.

Complex system requires better communication

The whold idea of communication is a process.  The more complex a dish becomes the more complex the explanations need to be. The same is true with software because the more complex the product the more detail and clear the communication needs to be.

Application communication can take on many forms including written documentation (recipes), verbal communication, and even video explanations. Cooking is a repeatable process It turns out that cooking is just a repeatable process and there are a lot of ingredients that go into making a great dish or dessert. The better the communication of the process the easy it is to follow, understand and repeat. The better the understanding a person has of the cooking process (and especially of the cooking science) the easier it is to create a something new. The same is true with software development. The better the communication the easier it is for others to understand. The more one understands about the science of software the easier it is to create something new and different.

America’s Test Kitchen

13 Ways to Improve Communication with your clients

14 Quick and Effective Communication Tips for the Time-Challenged

Published in: on October 26, 2009 at 09:22  Leave a Comment  
Tags: ,

Drinking from the Fire Hose of Information!

Drinking from the Fire Hose of Information or five things to do to improve status reporting.

When providing status of a problem it is important to provide the right level of detail, so the situation can be easily digested. A lot of technical team members provide status and it is like trying to get a drink of water from a fire hose. They tend to provide so much technical information the person on the receiving end is totally drenched in information, but thirsty for status.

 The objective is not that everyone understands the technical nuts and bolts of the problem; rather, the objective is to gain confidence the problem is being handled appropriately. Status should include items like:

1. Who are the customers impacted?
2. Have the customers been notified?
3. Have the customers been shown evidence the problem has been resolved?
4. What caused the problem?
5. What steps have been taken to make sure the problem does not reoccur?

Read more at Reboot! Rethinking and Restarting Software Development

The great exalted software guru measures time in bytes

The great exalted software guru measures time by the size of the USB drive I give to him. I brought with me a 16 GB USB drive able to fit on a key chain to give to the guru. I laid the new 16GB drive at his feet and the guru picked it up and examined it closely.

He said, “It has been a long time since you last visited.”

I asked, “How long has it been?”

The guru replied, “It has been 15 gigabytes ago.”

Yes, the guru was right it had been a long time. The guru said, “You first visited me 16 gigabytes ago.”

I said, “How can it be that I gave you a 16 gigabyte USB drive today and I have visited you many times before.”

The guru smiled and said, “Time begins now not yesterday.”

I thought I am going to need a bit more explanation than that and I started to speak and say, “Exalted software guru…”.

The guru held up his hand and I stopped. The guru continued and said, “In software the first day of learning starts today not yesterday.” I started to speak again and the guru held up his hand to stop me. The guru said, “skills that were useful yesterday are not useful today. Those skills you develop today will not be useful tomorrow. This is why software professionals need to learn something new every day.”

He reached under his rob and scratched himself. I felt a bit uncomfortable not knowing how to respond and then he pulled out a 5 ¼ floppy disk.

I thought, “640KB.”

He said, “no 720KB.”

I said, “16GB minus 720KB is really just about 16GB, so the 720KB is insignificant.”

 The guru smiled and said, “YES!, what you learned in the past may not be useful today or tomorrow.”

I asked, “if skills that I learn today are not useful tomorrow then why learn them today?”

The great exalted one held up his hand and said, “Why do you keep trying to interrupt me?” I apologized and he continued and said, “you need skills today and you need to learn tomorrow’s skills today too.” I nodded because I started to understand.

Just like he always does the guru picked up his new 16GB USB drive and walked back into his cave. He waved and said, “I will see you in a few terabytes.” It was his way of saying I will see you soon.

 I walked down the hill and thought what I had learned today. I need to learn something new every day about tomorrow. I can’t live off of the technical skills I learned in the past. Then I thought, “I wonder where I can buy a 1 terabyte USB drive.”

More from the guru…

Software Librarians

There is a job title in the software domain called software librarian. I searched for the job title of software librarian on Monster.Com.   It does not seem that software librarian jobs require any background in library science.   Instead the job description indicated they wanted someone who could code.  When I searched for medical librarian or law librarian the following appeared in every job description.

You must possess the following requirements and experience to succeed in this position: Master’s Degree in Library Science from an ALA accredited program.

What is the motivation for the fields of medicine and law to require a Masters in Library Science to organize their documents while there is no requirement whatsoever for the software industry?   These other industries have realized how critical it is to organize knowledge, so it can be retrieved and reused.

I suggested to a client they hire a librarian or two to help them organize their software application.    He looked at me and asked me one of those obvious questions, “where do we find a librarian.” I suggested he look for a librarian at the library which they did.  They hired two librarians to consult and help establish a numbering system similar to the Dewey Decimal System for their software applications.  Like the DDC their internal numbering system was a faceted system.  This allowed a lot of cross-referencing of documents. In the end they had an online system where they could search for documents by a specific part of the application.

A librarian, with a Masters degree in Library Science, makes between $36,980 and $56,960 per year.[i] The average salary of a software developer is around $69,240.  You can get a librarian for less than a programmer and they are going to be twice as productive (maybe more) as a software developer when it comes to organizing.

Read more at Reboot! Rethinking and Restarting Software Development – Interesting ideas on design and organization of website and information. – interesting ideas on how information is shifting.  It is coming to us in a variety different ways now.

[i] Bureau of Labor Statistics

Cloud Computing rhymes with Mainframe

It does not matter if we are talking about fashion, movies or even IT, things repeat.  Tie-dye, peace signs and 3D movies are making a comeback. Besides 3D movies there are a lot of  sequels and prequels movies too.  It seems like information technology (IT)  is repeating itself too.   Maybe not repeating but at least rhyming.   The latest trend in IT seems to be Cloud Computing.

In a land far far away and a long long time ago there were these things called mainframes.  A mainframe was  centralizedmainframe processing.  These mammoth computers were housed in large rooms with big air-conditioners and ran by men with black horn rimmed glasses.  Then there was a movement towards distributed processing and everyone would keep a copy of everything on their individual workstations.  There were proclamations that the mainframe was dead.

Don’t get me wrong here folks because there have been a lot of improvements from mainframes to Cloud Computing. All the talk about Cloud Computing sounds familiar.  Cloud computing succeeds where the mainframe failed.

With Cloud Computing I get to keep a copy of my files on my workstation.  This allows me to work when I am not even connected to the internet.  With mainframes everyone had a dumb terminal.  It was called dumb because it did not really do anything unless the terminal was physically attached to the mainframe.

Everything is automatically backed up!  Woo hoo!  I don’t have to worry about backing up critical files because they are in the “cloud.”

Since my files are synchronized across more than one workstation,  I can access my files from my laptop, my desktop and even someone else’s computer.


Since I am a self professed Apple head, I use a product called MobileMe.  MobileMe is classic Cloud Computing.  My wife never understood why the calendars on all our computers could not be synchronized, but now with MobileMe my wife can check or update calendars and contacts on any computer or device.  My iphone, my wife’s iphone, my laptop, all my iMacs and even my PC’s all stay perfectly synchronized just like a bunch of synchronized swimmers.

In the end the rumors of the mainframes death were greatly exaggerated .  They seem to be making a come back with a new name (cloud computing).   Cloud computing does offer much more than a mainframe and it succeeds in ways the mainframe failed.

Wait a second!  Tie-dye, Peace Signs, and Mainframes are all from the late 60’s and early 70’s.  What’s next miniskirts, flower power, and an energy crisis?

Read more at Reboot! Rethinking and Restarting Software Development

Published in: on June 24, 2009 at 10:24  Leave a Comment  
Tags: ,

Computers are like Women…

To be fair I need to post how computers are like women.

Computers are like Women…

…No one but the creator understands her internal logic.

… The native language they use to communicate with other computers is incomprehensible  to everyone else (men can’t understand women).

… Even the smallest mistakes are stored forever in long term memory.

… As soon as you make a commitment to one, you find yourself spending half your paycheck on accessories for it.

…You do the same thing for years, and suddenly it’s wrong.

The Software Guru Speaks Again

Whenever I get worried about the future of software development, I go up to the top of the mountain to see the Great Exalted Software Guru.

 A few days ago I found him sitting crossed legged in front of his cave in a robe reading a book about Zen and meditation.   I placed a new 3.0 gig USB drive at his feet and bowed gracefully.

 “Oh Master” I said,” please tell me the future of software development.”

 The Great One Said, “the past is the best indicator of the future.  Those who do not learn from the past are doomed to repeat their mistakes”

 “Wow that is really profound, did you make that up.”

 “There is no new knowledge only old knowledge packaged differently. “

 “Oh Master” I said, “but the in the past software developers and their leaders have made many mistakes.”

 The Great One nodded in agreement and replied, “yes, they will make more mistakes, and it gets worse before it gets better.”

 I said, “that sounds bad.”

 The exalted one said, “It could be good.  It is better to get worse before getting better than getting better before getting worse.”

 Thinking out loud I said, “Wow, I never thought of that.”

 The exalted one said, “That is why I am the exalted one.”

 The exalted one exalted, “Do you remember Y2K?  The software developers were wrong about that problem.  Do you remember dot com, they were wrong about that one too.  Do you remember when software started to outsource in the 90’s, wrong again.”

 I nodded yes in agreement.

 Then the great guru of software said, “software developers need to meditate on their customers problems not on the code.” 

 I was taking notes as quick as I could.   I said, “but the code” he interrupted me and exalted again, “do not focus on the code. The code will only lead you down the dark side.  The path of happiness is found in deep meditation about your customers problems.”

 I thought about these great words and I asked, “Will this actually happen in the world of software.  Will software developers try to understand their customers before they code?”

 The exalted one replied, “no, because software developers are slow learners and this why they make so many mistakes over and over again.  This can be the only explanation.”

 I was trying to digest this wisdom when the exalted one said, “I must go and watch Dr. Phil.”  Just like that he stood up picked up the USB drive and quietly walked into his cave.

More from the guru….

Little Errors in The Beginning…

Little errors in the beginning leads to great a one in the end, St. Thomas Aquinas.

Getting software requirements wrong has a ripple effect throughout the entire software life cycle.  These little errors can be missed, incomplete or just plain wrong requirements.

Some of the little errors are the result  of not knowing what needed to be known.  These type of mistakes can be excusable as long as they do not occur over and over again.  The problem, of course, with software development is these little errors occur over and over again because software developers refuse to address their responsibility creating these little errors.  Software developers and their management team shrug their shoulders and say, “you did not tell us you wanted that.  These little errors are the result of culpable ignorance or just plain ole fashion negligence.  The root cause of of little errors in the beginning is a fundamental lack of knowledge about the core business and especially the customer.

Too many in software development rely on the customer (end user) to tell them what they want.  As Tom Kelly points out in his book, The Art of Innovation, most customers do not have the vocabulary or the ability to describe what they want.  This my friends is is the root cause of all those little errors in the beginning.  The basic fundamental assumption that customers know what they want and they will be able to articulate what they want is just plain wrong.

Until software development understands that their core business does not have the ability to articulate what they want and especially what is missing, software development will never move forward as an industry.

Read more at the free online book Reboot!  Rethinking and Restarting Software Development.  (www.RebootRethink.Com)