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/

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)

Average Total Cost of Software Development

As an economist l like terms like Average Total Cost or unit cost. Average total cost is just total costs divided by output (quantity of the software produced). These terms are somewhat alien in the field of software development.

The problem is what a unit in software is and what represents total cost. Total Costs Total cost should include all costs to create and maintain the software product. It would include all requirements gathering, design, and analysis, coding, testing, maintaining and enhancing the software product. Many software organizations only include coding (or development) costs which greatly understate the actual cost of software development.

Labor costs are the most significant ingredient in software costs. Other costs can be training, software, equipment, travel, and entertainment.

Units
The amount of functionality delivered (see www.SoftwareMetrics.Com)

Average Total Costs
The equation is Total Cost divided by Units Produced. In terms of software it is total cost divided by function points (or functionality delivered). The lower the average cost the higher the rate of productivity.

Average Total Cost equals Average Variable Cost plus Average Fixed Costs

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/

The Heart of The Matter

I am asked all the time, how can I sell a metrics program in my organization.  The key word here is sell.  Any good salesperson will tell you the key to sales is benefits.

1. There is limited time management has to focus their attention.

• Management knows when to stay the course or change direction for projects.
• Control charts can be built with calculated upper and lower control limits.
• When any indicator is goes beyond a control limit corrective action can be taken.
• If the project indicators are within control limits, then management can focus on other projects needing their attention.

2. Clients will experience higher levels of satisfaction because communication improves.

• This will allow clients to have a better sense a project is on time.
• Clients will be notified of slippage in schedules sooner than later.  They will be able to notify those they have made commitments to.
• IT staff will be the recipient of better planning and project coordination.
• Management will make commitments based upon past historical performance not on best guessing.
• This prevents IT staff from trying to achieve and meet unreasonable deadlines.

3. Metrics allows IT staff members to become empowered.

• The likelihood of a lot of overtime at the end of a project decreases, so IT staff will not be required to work a lot of overtime.
• If an IT staff member (or team) is not performing up to standards, then corrective action can be taken
• Training
• Reassignment

A pint between friends!

Measure what is measurable, and make measurable what is not so.– Galileo Galilei (1564 – 1642)

I hope my British friends do not take offense to this, but the current measurement system in England is confusing.   Milk brought to the house by the infamous milkman is in pints, but the milk sold in stores is in liters.  “Petrol” stations sell gas in liters and advertise the price in gallons.  The distance between cities is in miles, but other road signs are in meters.   Of course, beer is sold in pints!  Everyone just knows when you walk into British pub you ask for a pint.

It is not uncommon to have local rules that dictate measurement.  Most people do not know that the volume of a UK pint is not the same volume of a USA pint.  One UK pint is equal to 1.20 USA pints.    A pint in the US is about twenty percent smaller by volume than a pint in the UK.  If a “pint” of beer is ordered in London, it is going to be about twenty percent larger than a pint of beer in the USA.  When my British friends order a pint of beer in the USA, they typically spend some time examining the size of the glass.  They often comment, “This doesn’t look right.”  They know something is wrong, but they just can’t identify it; they just can’t put their finger on it.

I have had CEOs tell me the same thing about their software organizations.  They tell me, “Things just don’t look right.”  Malcom Galdwell points out in his book Blink that intuition is often right, especially for those with a lot of experience.   The problem is that it is difficult to persuade someone based just upon intuition.   In the end, everyone should be able to explain and answer the question, “How do you know what you know?”   Without measurement, many people get attached to their beliefs and embrace all the emotions that go with their opinions.  In the absence of measurement and data, the person with the highest pay grade wins the argument that is based upon opinion.

I tell my British friends the reason a pint is smaller in the States is due to King George.  I tell them that King George taxed the colonist in America and shorted them on beer.  History tells us about taxation without representation, but fails to tell the story about the beer.

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

Cheers!

David Longstreet

Software Economist.