Agile Instructions and Training

Often Dilbert says it best. I do have to wonder what will be the next fad du jour for software development.

Scaling Music and Software

I am working on a lecture for my economics class about production theory.  Production theory works nicely for software development, music and    information workers too.

Output is the result of labor and capital.  The amount of music produced is the result of musicians (labor) and instruments (capital).    As more and more musicians are added to the process of making music the process of making music becomes more formal and there are overhead costs.

If we start with one musician playing a piano, then there is not much overhead required.  Add  three musicians and you get a quartet and there is some communication that needs to take place.  Add about 96 more musicians and you get an orchestra.

The cost per output (the average product) begins to rise because you have overhead costs.  If you have about 100 or so musicians you need a conductor.   Sheet music is required too (formal documentation not necessarily required for a small group).  We see the marginal cost, the cost to produce additional music, begins to rise.  The reason are additional labor is required that does not produce music directly.

This same model works for software development too.  Output for software is the amount of functionality produced.  As the project scales upward formal processes are just required.   There project resources (labor) required such as a project manager.  Formal methods and documentation is required to help in communication.

So there you have it…. Production theory works for information workers.

The End of Vaporware?

Software companies are being held accountable for problems in its software projects, misrepresenting what a software product does and being deceitful project timelines. A British judge also said the Red Sky software development company should have better understood the requirements of its customer. An earlier court ruling found that EDS misrepresented project timelines and was what its software product actually did. It sounds like the end of vaporware.

Red Sky sold hotel management software to London’s Kingsway Hall Hotel but the Hotel found problems with the software immediately. Kingsway Hall complained and called customer service and got customer no service instead. The software company knew of problems with its software and failed to disclose those problems because it wanted Kingsway to buy its software. It is simple as that. The question remains should a software company disclose known issues to its customers. It turns out British courts are saying yes. Red Sky should have told its customer of problems with the product when demonstrating it and chosen more demonstrations for it that more closely matched the customer’s own business requirements, the Court ruled.

Does any other industry believe or think they should not be held accountable for product flaws that may cause its customers harm or injury. Red Sky tried to rely on a clause in its standard terms and conditions which said that the only remedy available to customers if the software did not perform as advertised was to make use of its maintenance and support functions (a.k.a. call customer service).

Clause meant that Kingsway could not sue it for a refund on the software or for the additional costs it incurred as a result of its failings. The High Court disagreed and said that Red Sky’s clause was unfair under the Unfair Contract Terms Act. It said that this Act applied and protected Kingsway because negotiations between the companies had been one-sided on the issue of liability. His Honor Judge Toulmin also said that the software was not up to the tasks that Kingsway needed to use it for, and which Red Sky should have known were part of Kingsway’s needs when buying the product.

This decision is on the heels of an earlier decision. The High Court ruled that EDS had lied about its software when selling it to BSkyB and awarded interim damages of £270m (about $400 millions) against the software supplier – ouch! The court also agreed that EDS had been deceitful in pursuing the contract, finding that the information technology company had deliberately misrepresented how long it would take to complete the job. BSkyB Wins Legal Victory Against EDS –

http://online.wsj.com/article/SB10001424052748703906204575027303086931726.htmlHigh Court rules software liability clause not ‘reasonable’ http://www.channelregister.co.uk/2010/05/12/red_sky_liability_ruling/

New and Improved Software 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

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 http://www.softwaremetrics.com/Agile/

My Lord

This post has nothing to do with software because it is about traveling.  I was traveling in Europe last week and I caught a British Airways (BA) flight at London Heathrow Airport. BA allows you to choose a title when making reservations. In America we can choose a titles, and we can choose Mr; Mrs; Ms; and Dr. BA has a few more including Sir and Lord. I have to admit when I made my reservation I struggled between Lord and Sir. In the end I went with Lord.

I had a hectic day and I had forgotten about my new self proclaimed title. I checked in and provided my confirmation number and the BA ticket agent addressed me as “Lord Longstreet.” A smile came to my face and I thought, “Now that is what I am talking about.”  The ticket agent did not address me as My Grace or My Lord and I was a bit dissapointed.  While I like my self proclaimed  title of Lord, I think I need to upgrade to Duke or Earl. I like the sound of Duke David.

When the only tool you have is coding…

Abraham Maslow  once quipped,  “If you only have a hammer, you tend to see every problem as a nail.”  If the only tool you have is coding then you tend to see every problem as a programming problem.

Why do most diets not work? What does this have to do with software development?

Why do most diets not work and what does this have to do with software development? It turns out that diets don’t fail, but people fail to stick with the diet. The secret to losing weight is a pretty simple concept and hard to do. The secret, of course, is to eat less food, drink less booze, and exercise. The bottom line is if you burn more calories than you take in you will lose weight.

Most software process improvements don’t actually fail. People fail to stick with the process improvement just like most people fail to stick with a diet. When you think about it a diet is a process improvement plan too.

To stick with any process improvement takes a tremendous amount of discipline. It takes discipline to lose weight and it takes discipline to develop good software too. This little snack here or there adds up to a few extra pounds just like this little short cut here and there adds up crappie software.

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