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/

Methodologies and Fad de Jour

According to a recent study Agile is growing in popularity and not long ago the Capability Maturity Model (CMM) was the fad de jour. CMM was based upon sound scientific methods with plenty of data to support its case and Agile is based upon anecdotal evidence. It is not like there are small tweaks of ideas because the difference between CMM and Agile are tremendous.

What is it with software development that causes it to flirt with methodologies as often as weight loss methods? It is like the industry is floundering. It seems that some of the major consulting firms and experts in the field were proponents of CMM not long ago singing the praises of Agile. There seems to be an effort to support and to promote what is popular instead of what is right.

I believe the clue lies in why so many individuals experiment with weightless methods. Consumer Reports declared Weightwatchers the best success weight loss program, but its success rate is low. It is estimated that 95% of those using Weightwatchers eventually return to their old weight. It turns out people (especially Americans) do not have disciplined eating and exercise habits. It is so easy for us Americans to be overweight, to sit in front of the TV, or to spend countless hours surfing the internet. Our portions at restaurants are supersized and there is often an endless supply of snacks at work.
We could excuse the ebb and flow of methodologies on fact the field of software development is in its infancy stages, but I am not sure that is a good idea. In reality, those software companies that are the most disciplined have the highest rates of productivity and quality. This is true of world class athletes and musicians as well. It is especially true of world class golfers. A logical question is what does discipline look like in software development?

What makes software unique from other industries and disciplines is it is so easy to be undisciplined in our methods. It is easy to change a line of code compared to changing a physical structure or a building. The rhetorical question becomes if physical structures of a building could be changed as easily as software can be changed, then would architectural firms adopt the methods of software development?
I have studied hundreds of organizations around the globe as part of a merger or acquisition. It turns out those that are the most disciplined with repeatable processes are the most successful. It is critical to note that being disciplined does not guarantee success. It seems the missing ingredient is customer knowledge. The formula becomes those organizations with discipline and those that study the customer are the ones with world class performance levels.

Yet the unanswered question remains.  What are the reason so many software development organizations flirt with so many methodologies?

http://www.googobits.com/articles/625-the-skinny-on-fad-diets-what-really-works-what-definitively-doesnt.html

http://www.RebootRethink.Com

http://www.internetnews.com/dev-news/article.php/3841571

http://blog.nayima.be/category/agile/

http://www.sei.cmu.edu/cmmi/

Who moved my comfortable IT job (who moved my cheese)?

One of the best books on change is Who Moved My Cheese?  The book chronicles what happens to those that anticipate and welcome change and those that refuse to change.   The software industry is changing rapidly and I am sure that many are wondering who moved my cheese?  Who moved my comfortable IT job.   It is no longer about the technology it is about the business and customer.

The first wave of data processing is coming to an end which was internal development and B2B.  The second wave. B2C,  is underway and we are just at the start of this wave .  Business to consumer covers self service software applications deployed to the actual customer.

It use to be interviews with internal customers would suffice the requirements process.  Today, knowledge of the actual customer and the business is critical to the success of the requirements process and the success of a software application.  The big change is trying to understand the business and customer as much or more than the technology.

Read more at Reboot! Rethinking and Restarting Software Development.

Gather and communicating requirements using video

One of the best techniques I have seen for gathering and communicating requirements is video.  The customer is video taped discussing and actually working.    The team gathering requirements politely probes and the customer is asked open ended questions.  The problem gathering requirements is the customer often does not know what they want.  What they can tell you is how they currently do their jobs.

The reason why most IT organizations do not use video is because they do not have the skill set to video tape and to edit. It is as simple as that.

Read more at Reboot! Rethinking and Restarting Software Development.

Is documentation still relevant?

There was a great question posted on linkedin by Danielle Vokski.  Her question was, “Do you think that documented working procedures are still relevant in the changing climate of todays market?”

In todays changing and evolving market place there has to be a way to communicate and share ideas.   Documented work procedures do not have to be a written document.  It can be a video, podcast or an animation.

Keep in mind complexity does not necessarily equate to more documentation and a thicker user manual.  Consider the difference between an automatic transmission on a car versus a manual transmission. Clearly the automatic transmission is more complex, but requires much less documentation and user training than a manual transmission.

Another problem is if the environment changes then the procedures needs to change too.  The procedures become dated and useless if they are not changed.  Yet, the change needs to communicated to all those that are impacted by the change.

If the process is intuitive and/or the product is designed well, then it does not require much user documentation.   Don’t be confused because I am not advocating something like the code is the documentation.  What I am suggesting is the process has been studied so much and designed so well that it is intuitive.  If the process or product changes then it is intuitive how to adapt.

The documentation and skill required to repair an automatic transmission is much more than that of a manual transmission.  In the end whose perspective matters.

So let me answer Danielle’s original question with two answers.

1.  User documentation needs to become irrelevant. If the product is designed well and it is intuitive.

2.  Documentation is still relevant for the technical documentation.  The more complexity that is hidden away from the user the greater the skill to understand all the inter-workings.http://www.dotcodedump.com/2009/10/tips-for-effective-documentation/Read more at Reboot! Rethinking and Restarting Software Development

Links for writing better documentation

Tips for effective documentation –http://www.dotcodedump.com/2009/10/tips-for-effective-documentation

/http://techwriter.dk/writing/writing-good-documentation.html

“I will tell you… I don’t know…its Tradition!”

Some friends or mine David and Jo Cowdery operate a vineyard and winery in the south of France called Chateau La Bouscade. They have received several awards for their wines, so I was excited when  I received a couple of bottles wine from them.    What I found interesting is the bottles were sealed with screw caps not corks.   Since I do not know a lot about wine, I asked my friend Jo, “What’s up with the screw caps?”  She laughed and told me that screw caps were far superior than corks.  She told me that all the wines at Chateau La Bouscade have screw caps.   “Say it ain’t so, Jo!”

The scientific evidence is overwhelming that screw caps are better than corks in a bottle of wine.   It turns out a bottle of wine with a cork has at least a 1 in 10 chance of having cork taint.  Cork taint ain’t a good thing either.  It makes wine smell like shoes or a wet dog.

So what does this have to do with software? A lot. I have spent years gathering scientific evidence on the best methods to develop software and the scientific evidence is overwhelming.  I am not alone because organization like SEI and QAI share my findings.  Just like it is hard for get consumers of wine and wine makers to change it is hard to get software developers to abandon traditions.

So why do wine makers still use corks and how did this tradition get started?  Tevye a character in the Fiddler on the Roof sums it up nicely, “I will tell you… I don’t know…its Tradition!” The same can be said about software development.   I don’t know why so many software organizations refuse to adopt best practices.

There is an old proverb saying, “Seldom does Saul become Paul.” It means that seldom do people actually change.  What happens is a new generation has to grow up with the idea from the beginning.   There are pioneers like David Cowderoy who lead the way for a whole new generation of wine makers.    The new generation starts with the idea from the beginning.  A new generation of human factors engineers are going to be the future of software development.   These human factors engineers understand the importance of studying actual users and customers.  One best practice is to study the business and not to be passive in the requirements process.

I was speaking at a conference and I was asked the question,  “if things like metrics are such a good idea, then why don’t more software organization adopt metrics?”  I don’t know why?  I don’t know why people are overweight or why they smoke or why some wine makers still use corks.  I guess it is like Tevye says, “Tradition!”  Because It can’t be explained with logic.

Cheers!

Read more at Reboot! Rethinking and Restarting Software Development.

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

For my  non American friends
“Say it ain’t so Joe” is a reference to Shoeless Joe Jackson who was accused of fixing the outcome of  the 1919 World Series.  Legend has it that as Jackson was leaving the courthouse during the trial, a young boy begged of him, “Say it ain’t so,  Joe!” and that Joe did not respond.

To learn more about the argument of screw tops v. cork  see http://www.hoguecellars.com/feature/homework.html

Got Business Domain Knowledge? Here are five tips.

Here is some very specific techniques for studying and learning about the business domain.

1. Subscribe to the core business trade journals.  Every industry has trade journals.  For example,  the health care industry has Health Management Technology, Radiology Today, Digital Healthcare & Productivity, and Government Health IT.    All of these are free publications.

2.  Go to trade conferences that support the core business instead of just technical conferences and join subject matter expert groups.

3.  Read your companies annual report.  There is a lot of industry information it!

4.  Read your competitors annual reports.  Again, a ton of industry information!

5.  Visit the office of executive management (business side).  Ask the secretaries what the  executives are reading.  Explain to the secretary that you are trying to improve your business acumen. Trust me, this is a great idea.   Try to read what the business is reading.

Read more at Reboot! (http://www.RebootRethink.Com)

Mistakes in gathering requirements.

The worst possible way for the software requirements process is to have customers write up requirements and toss them over some imaginary wall.  The software development team works on the project for months and then shows up with a semi-completed project during acceptance testing.  Of course, the software is missing functions and does not work as desired by the client.  The problem is not that the business problem and solution changed during this time;  the problem is the business problem and solution were never defined.

Another common practice is sitting in a conference room with a customer and asking, “What do you want?”  Sitting in a conference room asking questions may not be a useful way to gather requirements, and it certainly should not be the only way.  This has nothing to do with how smart  or how good you are at asking questions.   Some developers will code what they thought the customer said and then show it to the customer.  This is commonly known as a code/test iteration.  A logical question is, “Why does it take so many code/test iterations to determine what a customer wants?” What were the reasons the developer and customer did not get it right in one or two tries (iterations)?  While this method is known as code/test, it is really a trial and error method to gather requirements.  The problem with trial and error is there are a lot of errors made along the way.

None of the solutions I mention actually address the root cause of the problem.   Many software professionals have thrown up their hands and accept that growth and changing functionality is just the nature of software development.  They incorrectly conclude the best strategy is to learn to adapt as the customer changes his or her mind.   In this scenario the solution to the problem is adaptation.   The teams need to be formed in such a manner so as to react as quickly as possible to the growing and changing environment.

The best way to gather requirements is to learn how to elicit requirements and study the core business.  The business analyst needs to be skilled at ethnology and a master of the metaphor.

You can read more in the free online book, Reboot!  Rethinking and Restarting Software Development, free at http://www.RebootRethink.Com

Danger, Will Robinson! Lost in Space?

I need someone to explain something to me.  Too often I hear the following statement.  “Our software is too complex to document, so we just code.”   Danger, Will Robinson!  Think about his from a logical perspective.

When software applications become very large or complex, it is hard to keep track of all the functionality contained within the application.   To really understand any complex system you need to use a technique called functional decomposition. So how do you perform a functional decomposition of a software application?   The basic idea is to divide a system into small logical parts. These logical parts are called elementary processes.  This technique works when solving complex mathematical equations, engineering systems, software applications and even your home entertainment system.

Before you begin to classify and organize your documentation, you will need a functional decomposition of your software applications.

• What are all those small parts (or elementary processes)?
• How are all these parts interconnected?

Danger, Will Robinson!  If you can’t perform a functional decomposition of your software application because it is too complex, then you software application is too complex.  You need to simplify it and you are probably lost in space.  It is not a matter of complexity, but a matter of not knowing how to properly document the software application.

How to Study Thy Customer

What always surprises me is how little software developers know about their own company and its industry.  The reason they know so little is because they have not taken any time to study.

One of the best ways to study customers is by using ethnological techniques.   Ethnological studies consist of looking  at what people do (behaviors), what they say (language), what they really do, what they make, and what they use (artifacts).   Too often what people say they do is not what they really do, and what they say they need to do their jobs is not what they really use.  It is important for the software developer to determine the real problem and the solution for the customers. Those software development organizations that are successful go to their customer jungle.  They follow their customers around trying to figure out how they actually work and what type of information is needed to complete the work.    They actually watch how their customers use the current applications.  They do not just rely on feedback they receive from user satisfaction surveys.

I practice what I preach.  Whenever I get a new client, I start to learn as much about their business domain as possible.  Since every industry has its own set of magazines, journals, organizations, and conferences, I start to subscribe to all these things in hopes of learning something about the business of my new client.  This is a common practice for an industrial designer.

Not long ago, I started consulting with a company specializing in the health care industry.  I subscribed to a series of free magazines such as Health Care Information Technology, Radiology Today, and Health Management Technology.   I also requested conference brochures. I am sure my mailman hates me because I get magazines and conference brochures from just about every industry now.  I read over these magazines and conference brochures to begin to learn about health care industry trends.  Back in the early 1980’s John Naisbitt wrote a bestseller book called Megatrends.  In his book he outlines in great detail how to study trends  and I use many of his ideas.

I learn the names of my client’s competitors.  I review annual reports, read articles and press releases. I make a list of my client’s competitors, a list of the top 5 trends, and a list of people I know in that industry.  Before I arrive at a client’s worksite I have a working knowledge of that industry. My background research is only a starting point for me.  Next I spend time at a client’s site studying them.

Read more at Reboot! Rethinking and Restarting Software Development.