New and Improved Software Job Titles

Software Psychologist – help software organizations over come its fears and phobias.

Software Psychiatrist – same as a software psychologist but they prescribe drugs.

Software Archeologist –dig around looking for project artifacts.

Software Paleontologist – dig around for looking for evidence the project actually existed.  They also theorize what killed projects.  It turns out most projects commit suicide. 

Software Actor – they don’t actually do any project work.  They just act like they are working.  Software Actors attend a lot of meetings and repeat what others say.  Software Theologist – pray for project success.

Software Plumber – unclog software projects.  This is not a glamorous job and it requires cleaning the project toilet.

Software Janitor –pick up after everyone else.

Software CSI – study the forensic evidence to determine if a project was murdered or committed suicide.  By the way most projects commit suicide.

Software Entomologist – collect all types of bugs found during the project.

Software Zoologist – studies all kinds of animals that work on software projects

Software Tap Dancer – dances around difficult project issues

Software Linguist - helps translates the native tongue of a software developer into English.

Read more at www.RebootRethink.Com

New Software Metric / WTF’s Per Minute

A friend of mine sent me this new software metric and it is being sold as the only valid measurement for software code quality.  Of course there are some obvious problems such as automating the collection and reporting of the WTF metric. On a positive note it appears that both senior managers and clients could easily grasp the results without a lot of explanation.

New Software Metric

Reboot! 4,000 Readers

Since publishing my online book  Reboot! Rethinking and Restarting Software Development in early February 2009 there has been 35,000 pages read by 4,000 different readers in 101 different countries.

The USA and India had the most readers with about 1,000  each followed by United Kingdom (250) and Canada (153).  What I find interesting are not the number of readers from countries known for software development, but the readers from countries such as Nepal, Moldova, or Zambia.   There were even a few readers from the Cayman Islands.  They need to step away from the laptop and get back to the beach!

Read more at www.RebootRethink.Com

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….

http://davidlongstreet.wordpress.com/2009/09/30/the-great-exalted-software-guru-measures-time-in-bytes/

Miracle Worker

One of my favorite movies scenes is in Star Trek III: In Search for Spock. Of course the Enterprise has some mechanical problems. Kirk asks Engineer Scott, “ Scotty, how long will it take to make the repairs.” Scotty replies, “8 weeks Captain, but you don’t have 8 weeks, so I will do it in 2 weeks.” Kirk asks, “Have you always multiplied you repair estimates by a factor of 4.” Scotty eagerly admits, “Of course. How do you think I keep my reputation as a miracle worker?” Scotty overestimates the amount of time it will take to fix the Enterprise and then delivers the project underestimate.

I often thought it would be lucrative to teach people how to become miracle workers.  I could teach people how to inflate their estimates and then deliver early and under budget.  When someone asks, “How did you come up with your estimate?”  Your answer could be something like, “I have 20 years of experience.”  That does not really answer the question, but it  works.  If your client still challenges your estimate then you could respond with something like, “You don’t understand the technology (shake your head and roll your eyes).”  Make sure to  add a few coding words to impress, confuse and intimidate your client.  This should get them to back down.

Read more at www.RebootRethink.Com

Gorillas and I.T. – Go to the jungle

Tom Kelly is an Industrial Designer for one of the most successful industrial design firms, IDEO. He writes in his book The Art of Innovation, “Your customers may lack the vocabulary to explain what’s wrong and especially what is missing.” Bingo! One has to start to ask the question, “If your customer does not know what he or she wants or cannot articulate what is wanted, then how exactly should the requirements process work?” Kelley writes, “It is common for well-meaning clients to duly inform us what a new product needs to do. They already ‘know’ how people use their products.” His firm does not rely on customers telling them about their problems. His book is full of stories recounting where customers were wrong about problems and possible solutions. His firm has learned to study customers and not rely on what they say. Kelley’s views are not unique, and his views are shared by many other industrial designers. Now if Kelley is right, and customers cannot articulate what they want, and especially what is missing, then how should the requirements process work?

Too often software development teams ask customers what do you want.  The problem is customers cannot articulate what they want.   Customers are unable to describe their own requirements.   The whole idea of gathering requirements is just wrong.

Gorillas and I.T.
Jane Goodall studied and learned about gorillas by studying them. She learned a lot from just observing and sometimes being among the gorillas. She utilized a technique known as ethnological study.  The best insights come from observation, interviews and informal conversations.

If you want to learn about your customer, then you need to go to the jungle.

The bottom line is software developers can learn a lot from industrial designers and other researchers.

Read more at Reboot! Rethinking and Restarting Software Development.

Jane Goodall Institute

What gets missed again, again, again, again…

I often get asked, “What are the common things that software developers miss.”  Hum… requirements.  Let me think about this a bit more, thinking, still thinking, yep it is  requirements.

Over the years I have collected a lot of data and I have had the opportunity to help customers determine why a software project was late or canceled.  The number one reason software projects were late or canceled was due to the fact that the end product requirements were not understood.  The far majority of these projects were greatly under-scoped.  In the end, the projects were a lot bigger than initially thought.

It is not uncommon for a software project to grow 300 precent from requirements to completion.  Yes, I wrote 300 percent.  The problem is that most I.T. organizations have no idea how much their software projects grow because they do not measure anything besides time and cost.  They do not measure functional growth.

So what gets missed, requirements.

Read more at www.RebootRethink.Com

“I believe you have my stapler” – infamous IT professionals

So how does the rest of the world see I.T.?   IT guys and gals are not portrayed favorably in movies, Television shows or commercials.  They are generally portrayed as rude, condescending and often as obese slobs.  Below are my favorite I.T. professionals and I have included videos where possible.

- Dennis Nerdy (Wayne Knight)  was the obese and obnoxious computer expert who tried to steal dinosaur embryos in the movie Jurassic Park.  His desk was a mess with stacks of paper and candy wrappers

- The beautiful Sandra Bullock plays a slightly overweight recluse programmer in the 1995 movie The Net.

- Who can forget Milton the obese programmer who clings to his red Swingline stapler in the classic 1999 movie Office Space.   “I believe you have my stapler.”  Initech was his company.  I have actually found a TPS timesheet. Don’t ask is it good for the customer, but ask is it good for the company?

- The British Office has their IT Guy (video) too.

- Saturday Night Live created Nick Burns the Company Computer Guy.   He fixes your computer then makes fun of you.

What’s sup chumps?

Another example is a Staples Commercial (see video).  They show a 20-something guy walking into work saying, “Sup chumps.” A manager says, ” I thought we got rid of that guy.”  The IT guy enters his office and begins to play computer games while another employee asks him to take a look at his computer.  The IT guy in the add says he’s on break and not to bother him.

So how does the rest of the world see I.T.?

Read more at www.RebootRethink.Com

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)

A software application should have no unnecessary functions!

Many years ago I learned a very important idea and this idea has stuck with me and benefited me.  The idea is E.B. White’s seventeenth rule in The Elements of Style:

Omit needless words.
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

A software application should have no unnecessary functions. Just like writing can be bloated a software application can be bloated too.   The reason software applications have unnecessary functionality is due to the fact the person designing the application did not have a clear understanding of what the person using the software application wanted to do.  Too often it seems like requirements just rain down on the software development team.

The question, “What do you want the software application to do? “ is an incomplete question.   To design a software application well requires the software designer to study how the user does his or her activities.  A software application needs to be designed so it fits naturally into the flow of work or activity.

If the software designer has not studied how a person works and designs the software around the natural work flow, then there is a high probability the software application will be bloated and a lot of unnecessary functionality created.   It would be nice if the rule was expanded and would read as follows.

Omit needless functions
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines, a machine no unnecessary parts and a software application no unnecessary functions.

For more read the free online book www.RebootRethink.Com