Got industry experience?

Often I find myself just sitting around thinking.  The other day I started searching several online job posting websites.  I was wondering if other disciplines require  knowledge  of the core business.  In my quest to figure this out I reviewed over 500 job postings for a variety of different technical disciplines including mechanical engineer, electrical engineer, chemist, and biologist.  In each case, over 90 percent of the job postings required industry domain expertise.   For example, a job posting for a mechanical engineer required 11-14 years of experience in production packaging of electronic equipment.   The same was true for chemist and nearly all chemist jobs required domain experience or knowledge of the core business.

Let me stop and review.   If you are a chemist then your future employer wants you to know about chemistry and the industry (core business).  The same is true if you are a mechanical engineer or electrical engineer.

This is in sharp contrast to software development.  When I examined job posting after job posting, almost none required any knowledge about the core business.   Out of 100 job postings for software developers that I  reviewed only 4 required industry domain knowledge.   Think about this for a second.   Poor  requirements plague the software industry.  Do ya think it has anything to do with the fact most software developers have no knowledge of the core business?  Come on folks!

One could argue that it is better to be a generalist instead of a specialist, but no other industry suffers as many project failures has software development.  No other industry frustrates end users like the software industry.  No other industry has such a problem with requirements as the software industry.

Read more at Reboot! Rethinking and Restarting Software Development

Advertisements

Pair Programming versus Cheech & Chong

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

Read More at 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 job check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

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

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

Published in: on April 30, 2009 at 18:59  Comments (2)  
Tags: ,

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

New Software Metric

Published in: on April 29, 2009 at 19:03  Comments (3)  
Tags: ,

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

https://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