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 http://www.americastestkitchen.com/corp/about-americastestkitchen.asp

13 Ways to Improve Communication with your clients
http://designm.ag/freelance/communication-with-clients/

14 Quick and Effective Communication Tips for the Time-Challenged

http://www.sitepoint.com/blogs/2009/10/12/quick-communication-tips/

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

Stone Cold Coder meets Diva Developer!

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

Professional Wrestling –http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

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…

https://davidlongstreet.wordpress.com/2009/04/27/the-software-guru-speaks-again/

Pay no attention to the little man behind the curtain!

The little dog Toto pulls back the curtain and exposes the Wizard.    In this most embarrassing moment the Wizard thunders out, “pay no attention to the little man behind the curtain.”  Well, there are many IT organizations and IT “professionals” saying the same thing these days.  Too many IT professionals are Wizards pretending to be something they are not.  They manipulate knobs and dials creating a lot of smoke and noise.  They give the appearance what they are doing is really complex and sometimes even frightening.   When challenged they will speak in techno talk in hopes they will not be challenged.

 Over the years, I have pulled back a lot of IT curtains and heard over and over again “pay not attention to the little man behind the curtain.”

Watch out for fling monkeys too!

Read more at Reboot! Rethink and Restarting Software Development

Movie Making and Software Development

The role of the project manager and software manger are often missed understood. Movie making and software development are very similar types of creation.  A brief examination of movie making and comparing the roles of director and producer will give some insight on the differences of the project manager and software manager.

The director of a movie is similar to an IT Manager.  They are responsible for day to day activities.  It is common for many directors to not have any acting experience.  For example Steven Spielberg, winner of numerous academy awards, has never acted.  On the other hand Clint Eastwood was an acclaimed actor prior to becoming an award winning director.  The directors, like an IT manager, is responsible for the management of staff.

There are many technical aspects the film producer need to coordinate.  Besides the actors and actresses it is important to have the right film crew, lighting, sound, editors, animators, so on and so forth.  The producer may or may not have intimate knowledge of any of the technical roles.  The software project manager is responsible for getting the right business analysts, coders, testers, software engineers for a project.

Producers like the software project manager are responsible for the planning and the execution of the budget and insure the project comes in on budget and schedule.  An executive producer may coordinate the activities of several producers similar to the role of a project management office.

———————————————-

Who does what? http://www.directortom.com/director-tom/2007/8/17/executive-producer-producer-director-who-does-what.html


A production manager – a rose by any other  name

http://filmindustrybloggers.com/blog/2009/10/13/the-production-manager-a-rose-by-any-other-name%E2%80%A6/

Technical Support Cheat Sheet – Cartoon

A friend of mine sent me this cartoon that outlines the steps necessary to solve most technical problem. The great thing about this cartoon is that helps people learn the steps necessary to solve problems instead of providing an answer.

Technical Support Cheat Sheet

Technical Support Cheat Sheet

Read  more at Reboot! Rethinking and Restarting Software Development

Published in: on August 24, 2009 at 11:20  Comments (2)  
Tags: , ,

Is software an art form?

If software was truly an art form, then the same adjectives used to describe art would be used to describe software.   I often software developers ask, “What three words best describe your software applications.”    Seldom do I hear words like, beautiful, elegant, sophisticated or graceful.   On the other hand,  I have had many  say, “Alt, Control, Delete.”

Published in: on August 5, 2009 at 06:56  Comments (1)  
Tags: ,

IT the toilet that never stops flushing

I was consulting for a large international firm and one of the executives on the business side made the comment that, “IT is the Toilet that never stops Flushing.” To often this is an accurate phrase to describe how money is spent in IT. Most of us have had a running toilet in our bathrooms and it can be very annoying. In the end a running toilet is just money down the drain and too often spending money on IT is money down the toilet too.

Over the past 20 years a lot of IT spending was done without careful cost benefit analysis.  Too many projects were undertaken because there was a desire to move to the latest and greatest technology.  The current recession is causing IT to really justify its spending.   The business is forcing IT to wiggle the handle to see if they can’t stop the water from running.

Even though the current fade de jour is build as you go or ad hoc software development it is an expensive proposition.  Those IT organizations that embrace, study, and learn  the core business are the same organizations with the highest productivity rates, best quality and lowest costs per unit.

Read more at Reboot! Rethinking and Restarting Software Development

TPS Reports and Cover Sheets

Too often people are asked to record their time or report data and are clueless the reason.   They start thinking, “what’s the

initech

initech

point?”  They think of the ole, “IniTech – T.P.S. report” from the movie Office Space (TPS Time Sheets & Cover Sheet).

When people see how the data is being used, the value, “what’s in it for me”, then they are more likely to input data correctly and sometimes enthusiastically.

When I develop metrics for an organization, I have to rely on the quality of time sheets. Often people tell me the time sheet data is no good. If I am building estimating models based upon past data and the data is no good, then, the estimating model is going to be wrong too! I have to make a lot of adjustments to the historical data. Knowing how people spend their time on past projects is an invaluable management tool when planning for future projects. When projects are planned properly there is less chaos and often less overtime. Overtime is often the result of poor planning and poor estimating.

Read more at Reboot! Rethinking and Restating Software Development.

TPS Initech Time Sheets

Published in: on July 20, 2009 at 23:01  Comments (1)  
Tags: ,

Just Google it! Huh?

There is a misconception it is okay to have documentation scattered about individual computers and a “shared drive.”  The myth is documentation can be found via searches and it does not need to be organized.  Some organizations want to implement a Google style search mechanism.  The beauty of the Google search engine is it seems so simple.  Google relies on creators of websites linking information together and some relatively complex algorithms.  The founders of Google wrote a paper entitled, The Anatomy of a Large Scale Hypertextual Web Search Engine outlining how the Google search engine would work.   It is not as simple as it looks.  Most organizations with disorganized documentation cannot get their developers to use consistent terminology nor can they get them to embed hyperlinks in a document.

If a specific document is referenced by many other documents, then the document is significant.  If the document is not be referenced via some linking mechanism, then there is no way to determine its significance. The problem, of course, is getting individuals to link documents together.   Believe it or not I have had developers argue this point.   Even though they have never read the short paper or long paper written by Brin and Page the founders of Google they just somehow know all the inter-workings of Google.  They think it would be easier to design a complex search engine with artificial intelligence not yet invented by mankind instead of standardizing terminology and using some sort of naming convention for their documents.

Read more at Reboot! Rethinking and Restarting Software Development.

http://infolab.stanford.edu/~backrub/google.html