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