Hello Readers!

Who would've thought you'd ever need to reboot your dishwasher, or be able to crash your car without leaving the garage? Those days have arrived; software is becoming more pervasive all the time. Unfortunately, software isn't as reliable as it ought to be, and its inherent unreliability is passed on to every system it touches. And while consumers would like software to be perfect before they ever encounter it, perfect software doesn't exist; however, deciding when it's "good enough" to release is no simple task. Project managers frequently must make tough calls when it comes to deciding when software is ready to market. There are deadlines that must be met and other pressures to consider, and sometimes the actual functionality of the program suffers. Not to mention the hidden costs of rushing a product to market.

Today's article by Taran Rampersad offers some advice to project managers who are planning to release software. Read on to find out if your project is “SOUP” yet. Enjoy!

Knowing when software should be released: Is It SOUP Yet?
By Taran Rampersad

In a classical software project, it's easy to tell when software is ready to be released. It has to fulfill the requirements, it has to have passed testing, and it has to be ready for the user. It has to have the appropriate documentation and/or user's manual and/or online help. But, is it Software Operating Usably and Properly (SOUP)?

With so much software being produced throughout the world (made available across the Internet) some important things are being forgotten. When software is released, it's supposed to be usable, it's supposed to show that the company or group of people who have developed the software are professionals, and that they know what they are doing. The difference between good SOUP and bad SOUP is really up to the user, but there are many things that the people developing the software need to address before the software is released.

How little functionality is too little functionality? How much usability is enough? These are questions that have to be addressed, and within a customer driven project (one which the customer is actively involved in, such as a proprietary project for a specific customer, or Open Source/Free Software), these issues are taken care of on the fly – the customer is involved in all aspects of the development, and have a steady rapport with the development team.

In other types of software projects – such as new types of applications (and even new operating systems), the target is a moving one, and is difficult to assess. Typically, the potential customers won't even know that they want the product, or how they would use it – and because of this, SOUP is that much more important to these projects.

Marketing an incomplete product with features that haven't been tested yet increases expectations, and is good business in the classical sense. The risk, though, is that expectations will not be met – and the users will see bugs in their SOUP.

This article is intended for these types of software projects – and mainly for project managers and IT managers involved in software projects, though many developers may find it useful.

SOUP?

When software hits the market, it is useless if it doesn't do something. It's also useless if the user considers it unusable – and these are difficult things to judge. When creating an application independent of the potential users, it's important to have an idea of who will be using it, and how they will be using it. In a world where everyone is creating better software mousetraps, it's important that these mousetraps still catch mice.

Limited functionality is understandable in the first release of an application, but it should have enough functionality that the user will not only use it, but continue using it. In a world where reading the manual seems obsolete, users will walk away from an application if it is too difficult for them to use. What's more, if there is advertised functionality in it that doesn't work, the software will be shelved, and something new found to fill the void.

What really makes for bad SOUP is when an application has a lot of functionality, and it's very hard to get to. If the interface doesn't permit for intuitive use, then as far as the average user is concerned, the functionality is missing. One can also go too far, and have so much functionality available to the user that it's befuddling. Know your users, know your SOUP. No users, no SOUP.

Putting out good SOUP is important for these reasons alone – but if you factor in the reputation of the developing company and group, you begin to see how it can affect future ventures – and how perfectly good SOUP in the future can be adversely affected by bad SOUP preceding it. Odds are good that if you get bad soup at a restaurant, you'll not go back. If you do, you deserve what you get.

Schedule vs. SOUP

In many present models of software development, such as the Spiral Model and Concurrent Engineering models, prototyping and changes to the prototype are made recursively – this is also seen at an extremely high and professional level within the Free Software and Open Source communities. Everyone is working on a schedule; everyone is trying to get the project done on time, and, whether it's a proprietary project or not, there's a schedule involved.

In a new type of application, the requirements can be quite loose, and because of that, so can the testing. In a well managed software project life cycle, the testing is reassessed throughout the project, as these needs change.

Anyone who has worked on a software project before knows that a schedule is a difficult thing, and sometimes the schedule has to override some features and/or functionality to get the product to market. But how much is too much? This is where many developers and software companies have done something extraordinary in the way of marketing – they make their product 'freeware', 'shareware' or even 'nagware' for a limited time, or with limited functionality – and they sit and wait for feedback, and work on the issues as they come. Yet even this doesn't guarantee good SOUP.

It's much easier to define bad SOUP. No matter what the schedule requirements, bad SOUP should be avoided so that the developers/development company remains credible (at the least!). A few things that guarantee this are:

(1)If the application is advertised to do something – make sure it does it, and make sure that the users can do it easily – and without a manual. (2)If there is functionality planned for the future, but it is not available now – don't have menu items available to the user. Period. (3)Test the software, and kill the major bugs. If bugs are evident upon release, make it known, and make it known that you are aware of them and working them out. (4)If your software isn't ready for a software review – don't request one! A bad review can do untold harm to the use of your application – no matter how functional and usable it is later. A good review only comes through good SOUP. If it's a beta, let the reviewer know! (5)If customers are paying to access more functionality, it better work! These four things lend to a more credible product. If your customers are paying for the software to use it, these are so much more important than a 'try-and-buy' pieces of software. Developers Know SOUP It's important to listen to the development team when it comes to SOUP – typically, the developers will have a low comfort level with bad SOUP, and a high comfort level with good SOUP. When a developer says, “The SOUP is not done.”, heed their advice!

Certainly, there are business decisions to be made and there are schedules to be met, but most developers can understand that – and they also understand that an inferior product works against, instead of for. More than likely, these are the developers who will be doing maintenance on the software – and as such, have a personal investment in the product.

A better working product means less work later. Developers, despite what you may think, don't always enjoy maintenance.

Refining the SOUP

As the software is released and use by the customers, the SOUP is refined more and more – if the customers have an easy way of communicating, and you're responsive, things work out well. If not, your SOUP, over time, becomes bad SOUP. Nobody likes bad SOUP. The software has to evolve with the user's expectations, and meet their needs. Encouraging the emails that start with, “Wouldn't it be nice if...” is also of great importance. Users can really help in this process. Meanwhile, the developers who are maintaining the software may come up with better ways of doing things in the background, which makes even better SOUP.

Why Isn't Anyone Eating my SOUP?

Alas, this is the toughest of questions – it could be marketing, it could be that nobody really has a use for your application – or, even worse, you may have bad SOUP in your lap (despite how good you may think it is). In cases such as this, it's imperative to actively communicate with the users who have tried or are using your application – and find out why they aren't using it.

It could be that you have very good SOUP, and nobody knows about it. It could be that they found a bug in your SOUP, and it was easier to replace it with another piece of software rather than email you about your bug. Worse yet, they could have emailed you about the bug in the SOUP, and your customer service and Bug Slaying departments were asleep at the keyboard.

Is It SOUP Yet?

In the end, great care must be taken in ensuring that software works for the user. It should not restrict them intentionally, and it should be easy to use. Good testing should shake out the majority of the big bugs, and squash most of the little ones. If some functionality is planned in the future but is not there at the time of release – do yourself a favor and make sure that you don't make it 'available' to the user through menus or configuration settings. The support for it should be fast and effective – releasing software without the ability to support it has been the demise of many a good application. Quick, knowledgeable responses are important – and so are personal touches. Good support treats people like human beings. If they were applications, after all, we could fix them instead of the SOUP! Before you release that next killer application on the unsuspecting public, make sure it's good SOUP. Your reputation is on the line.

Taran Rampersad is an independent software developer, writer and consultant who has been eating too much SOUP lately. If you wish to send him solid food, you may check out his personal site at www.KnowProSE.com.