Developing Great Software that Changes People’s Lives
Software development is not just about using technology to solve problems. Rather it is about offering tangible value. A good software developer hopes his or her effort will result in something that will be liked and used by someone. However the truth is that a vast majority of the software out in the world produces one common emotion in people – frustration.
I am considering two different types of software applications in this article. On one hand, we have shrink wrapped software written by some independent software vendor (ISV), and on the other we have applications written by the software department of a non-ISV to support the firm’s internal or external business processes. There are interesting differences between the two.
Lets consider the non-ISV software first.
In today’s world, the workforce is a moving target. Under such scenarios, software built to support internal processes are primarily of two types. Commercial Off the Shelf (COTS) or custom developed applications.
COTS is some software vendor’s idea of how your business might do its business with customization. Custom developed applications are a result of the workforce’s idea of how business must be done, or at least the idea of someone in the workforce.
If the workforce is changing, then present reality may not be real tomorrow. Hence by definition the internal systems will lag behind the changes occurring in the business place. The systems will not be proactive agents of change.
Inevitably, such systems will lead to frustration for people using them as well as people responsible for their upkeep.
For ISVs, its challenging to build something for a huge indeterminate audience. Using software essentially involves engaging in specific behaviors. To a large extent, the software will force the users to choose from a some specific set of behaviors.
This scenario by definition means change in user’s habits while interacting with the computer.
A great software product is a pleasure to use, irrespective of the goal you are trying to accomplish. Whether it is a customer service representative, recording the call or a commodity trader making a trade, the interaction should induce a sense of fulfillment.
Any repetitive task will eventually get boring. I do not know of any school of software which advocates boring programs. Yet, product after product are churned out barely making the grade. Why? It due to the fact that most software designers cannot imagine seeing their user in action, not just for a day but day after day of interaction with their software applications.
Why does the typical software application have the appeal similar to a mathematics problem solved on a page in a notebook? Add a new customer, edit details, update your account etc. Endless such programs are created causing emotional nausea among users.
Who among us knows of users that exclaim that the part of their job that they love is the opportunity to use the software to “Update Customer Detail” or fill endless computer forms without feeling stupid or someone telling them that “they do not know how to use the software properly”.
Fixed context problem solving approach.
Whenever a new application is written, it is from the viewpoint of a fixed domain, or fixed context. “We need a customer management application, Bob.” It should be able to interface with our multiple vendor systems, our inventory systems and our data mining applications. Great! Yet another piece of misery inflicted upon some wheel in the process workflow, forced to submit to the software’s dictates, entering information, producing reports, wondering why they didn’t take up the art as a career instead.
Instead, what if the executive were to say, we need a software application that makes it fun for customer service representatives to manage our customers, gets the job done in the simplest possible way, and actually makes it visible to the representative what impact did the actions make, while making it fun for them.
How about a trading application that actually allows me to become a better trader, not simply being the fastest trade and real time data enabler. Isn’t that my primary goal, be a better trader to be able to make more money? Now, such software would be truly revolutionary.
For most software developers, the computer and the person complete the equation in terms of the context. Well, we couldn’t be more wrong when approaching software applications. The entire domain of workplace is ignored in most software applications.
Where your customers are? Why are they there?
Are people talking to other people while using your software? Does the user have ten instant messaging windows open? What if they have to leave the work half-way and evacuate for a fire-drill?
A fifty field form submission is denied because the software does not like the way you entered your zip code. If zip code was absolutely essential wouldn’t you get all the letters back from the Post Office saying, “Thanks for making the trip to the Post Office and dropping your letter. Unfortunately, you forgot to write down the zip code, and you must complete this and drop the letter again.”
Writing an application for commodity traders to trade and an application for a point of sales clerk to complete a transaction, completely different scenarios, yet we can hear the argument, well only the user interface is different. Any good developer can write all the other parts for the application without any problems. But it is the whole environment which should guide the application development from end to end. We cannot isolate it to just user interface differences. Different environments, different needs and hence completely different understanding of how to build that software that could change people’s lives.
“It’s something that I cannot live without”. Is your software producing this emotion in your users? It’s important to ask this question again and again during development and subsequently as well. It will allow you to get rid of annoyances from the beginning. A lot of time I hear in development meetings, “Yes I know this will be annoying to the user, but…… “. How can we even dare to keep our users in contempt and follow such sentences by something that’s usually making our (the development team) lives simpler.
Such mentality results from partly the way technology progresses.
In the software marketplace, there are companies that are creating the mass production framework and technologies which hungry IT houses and ISV devour till the technology runs out of steam or something new comes along. A firm that I worked at, spent couple of decades building a large unwieldy infrastructure in one platform only to start abandoning it in favor of newer technologies. How do they expect innovation and a quick ROI if no proactive and adaptive frame of mind existed for over two decades?
There is a great lag between building software and keeping it exceeding user expectation on a continuous basis. Most software companies do a poor job f letting the customers even feed into the priorities and expectation for future version of the software. Imagine a company that sells you some software with a promise that within one and half month of your initial purchase and use, you will see another version of the same product fitting your needs more closely. Wouldn’t that be an exciting proposition?
Of course, you cannot let the users direct the innovation your company is producing, but can you at least take them along on the ride and let them feel that their concerns do matter and will be addressed. I find that lacking tremendously in most packaged software out there. Something of this nature would be a nightmare to implement with a hardware product (imagine buying an Ipod with the promise that within a month, they are going to give you a better version based on your usage of the product).
It is not only possible but must be done on a ongoing basis. Imagine a company that doesn’t leave you once your credit card has been charged. Wouldn’t this spawn off some new methodologies for building software packages. Millions of dollars are spent on creating, maintaining and running expensive software application. I cannot imagine how little of this money goes into an active feedback cycle upon deployment.
The truth is that we as users expect very little from software. Majority of users are not demanding. They submit to the whims of the software rather than be more demanding. Only eight percent of VCR owners know how to program it. Why? We simply found it too challenging and did not demand simpler ways to program it.
I don’t know how many developers I have seen who have no real desire or passion to put the product into the hands of real customers. They are well meaning people, but beyond solving a particular software problem, the interest wanes on seeing it in action in user’s hands. That’s someone else’s job in their mind. They could be building the most complex and satisfying application, but the desire to see it in action with happy end users is almost non-existent even in most supercharged teams.
An important piece missing from traditional software life cycles is production software experiences and its incorporation into software itself. I have seen lifecycles talk about maintenance and warranty, but critically lack talking about any real means to observe, record, incorporate feedback from real users into the software product itself. To this regard, even eXtreme programming talks about involving users into sequential iterations but all change must come from the embedded user or representative into the team. There is practice listed which states that software is never really done and is similar to an evolving species. (Survival of the fittest software theory)
How would users react to the fact that they are being delivered “unfinished” software. It would be the honest thing to do. Couple it with a guaranteed promise of evolving software. There is hope in such a tool. How many software vendors promise user input manner, but how hard is it for an average user to make the opinion known and see it actually make a difference. I see no standard way that organizations do product improvement based on user feedback.
Improvement is not the same thing as innovation. Innovation is thinking of something that does not exist yet and certainly we cannot delegate this important task to user feedback alone.
In the next part we will examine Innovation in greater detail. How we have progressed from text based interfaces to today varied means of accessing information and interacting with it.
Any software that needs long training phase and a lag phase before user becomes productive on it, is expensive from the business point of view. Rarely, the cost of user training is built into the costing of software development. A truer picture will only emerge when vendors start incorporating the cost of end user training into the total cost incurred by the buyer.
If a user can learn the core functionality of a product in less than an hour, we can say that the software package is pretty lean on its training needs. Lengthy training periods tend to overwhelm hapless users and they generally gravitate towards using simpler software.
Compare the way Microsoft implemented Search in the Desktop to the way Google searches the whole World Wide Web. We know who the winner is.
Pebble Drop Approach
Even a tiny pebble tossed into the calm waters creates a ripple effect. Similarly, each software product put out to the users has the possibility of creating ripple effects into how they interact with the computer and do their business. Unfortunately, most software development processes end once the software is deployed and do not harness the energy created by this ripple. A tremendous opportunity is lost here.
You have got someone to use the software written by you. But you have put little or no formal methodical effort into gaining insight by measuring and quantifying their reactions to the software.
Most software development processes ignore this part of the life cycle. It’s a mistaken belief that the software development life cycle ends with delivery of the product or lives on in a dormant fashion during the maintenance phase.
Indeed some organizations utilize the beta testing phase to gather feedback about the upcoming product and also glean information about bugs that have slipped their development cycle. The beta users represent a fraction of the actual users. Big decisions about the product are generally taken by this time. Beta users can suggest improvements however; it is unlikely their feedback has a major impact on direction of the product. Also majority of the beta users are using the product in a “testing” mode. They are usually advanced users and are likely to view the product from the point of view of a wider spectrum.
Why would I buy Version 1.0?
If the customer knows that you are coming out with version 2.0 soon why
should they bother looking at version 1.0. This continues to be a genuine risk area for hardware products, which cost more and not quickly upgraded or replaced.
A customer wants version 1.0 of a product, for the following reasons:
- The need outweighs the rationale of waiting for a better version
- Version 1.0 can be used in a different capacity upon upgrading
- Version 2.0 is cheaper to upgrade than buy anew.
- Many important needs are already fulfilled by version 1.0 right now.
This entry was written by , posted on December 24, 2007 at 1:00 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.