User Feedback in Software Development

Feedback helps you clarify your understanding. Feedback helps you see things in new ways. Feedback helps you correct your course. Feedback helps you learn.  Feedback makes you and your work better. Whether you follow specific Agile practices or not, feedback early and often is a critical component of being more successful.”[1]

1 Introduction

Software, more or less, is all about satisfying user’s requirements. We can somehow say and believe that, although bugs may exist, a software is still a good one if most of its users have no complaint about it after using for a long time.

Therefore, more and more attentions have been paid to user feedback since long time ago. Software companies want to know what do their users really think of their products, which aspect do they care the most, what functionality are they still expecting for and so on. They want to learn as much as possible from their users in order to improve their product quality.

This article is going to talk more about the importance of user feedback in software development, list some points that developers should learn from the user feedback, and finally, give some suggestions about how to make better user feedback form.

2 The Importance of User Feedback

User feedback is important to all kinds of product development, and software is no exception. However, different to others, software development also has its own features which makes the role of user feedback more important.

First of all, unlike building a house or making a chair, there is no reference for software development, even if build the same software, failures happened time to time. Although the developers can write some test cases, but those test cases are still from the view of the developers and more often depends on the system environment. The only way the developer can know whether the software works or not is by letting users try them. Only when they receive feedback from the users can they know what’s going on.

Second, unlike any other virtual product, for example TV program, the product team need to get lots of feedback to get a general idea about what audiences think about the program. Even only one user feedback can be useful for software development. The developer team can then know whether the software works or not, and if not, what’s the problem. Using my own experience as example, I am doing my honors project now which is about a device for biology experiment. Since this is just a undergraduate project and perhaps will only be used in the university, not much “users” are expected. After finish implementing the code, I did write some test cases, and seems the code is all fine. Then, I invited one of my friend, let him install the software on his machine, and when he ran the software, bugs had been found, that the configuration file I used was for 64-bit windows 7 OS and it does not work on his 32-bit windows 7 OS. Not much user feedback, only one and it helps.

Besides, updates are frequent along software development. Especially for mobile applications, if an application stop updating for several months or even several weeks, people will use other applications with similar functions instead. Releasing new version of a software is itself a big issue. Lots of things need to be concerned. However, in terms of user feedback. On the one hand, it helps developer team learning which parts of the software do users like or expect the most, they can then give higher priority to those parts while developing for the next version; On the other hand, it also tells the developer team if there is any serious bugs that need to be fixed immediately.

Finally, it is widely accepted that positive user feedback will make the development team much more confident and is helpful more team management.

 

2 User Feedback Form

Although in some degree, software product user feedback is quite different to other kinds of products, while talking about the feedback form, they are more or less the same.In general, there are three aspects we can talk about user feedback form: content, means of communication and display(if user submit form online).

Content. In fact, strictly speaking, there is a difference between software product and others, and that is about bug report. Since in most of the cases, users are not expert in the area of the product they are using, they can’t describe the failures or the problems precisely. Even though we get some feedback or bug reports from them, we may still don’t know what’s going on, so the feedbacks become worthless. However, the advantage of software products in terms of this is that whenever a program crashed or failed, we can always automatically generate a bug report which contains the error message(figure 2.1). Users even don’t need to add anything else in the report, developers will still be able to know what was the problem. And better designed software also use code to represent different errors, which makes debugging more easier.

 error_RDP_ManagerFigure 2.1 bug report[2]

 

Expect from the bug report, anything else between normal product and software product in terms of the content of the feedback form are the same. Developer team should make sure what do they really want to know about their product from the users and contain those aspects in the form. A general overview seems not as useful as view in details, but sometimes is still necessary, company can display these overview to new users, and help them decide whether purchase our product or not. Besides, in order to get further information, user’s contact information may also asked (optional).

Means. Although making phone calls can be the most efficiency method for most product, for those non-commercial software, we hardly ever hear the companies call their users and ask about feedback. On the one hand, contact details is not necessary when users registered to use the product. On the other hand, compared with other products, software have much more amount of users, making calls takes more time and is not convenient. The better solutions are sending emails or just a simple report message which contains the form.

Display. There is a most important principle, that is make the form as simple as possible. Instead of letting users type in things, it’s better to let them select. Users won’t be bothered spend 15 minutes giving feedback for nothing, a quick ask and answer could be much better. Also be polite and using attractive words, we should somehow make our users feel that we indeed take their opinion into consider, what they give us won’t be throw to the bin directly. Finally, when should we ask them to send feedback? From the point of a user of some software, I would prefer to give feedback either after being used a software for a long time or when I decide to uninstall it(figure 2.2), and the reason for that is I think this will indeed help the developers know about why their product is not welcomed.

 uninstall_feedbackFigure 2.2: uninstall feedback[3]

3 Conclusion

There are definitely more things we can talk about user feedback, software companies can also make better and better feedback forms. However, it is true that the quality of the product is always the most important thing during software development. No matter how well we know our customers, if we can’t meet their requirements, it means nothing. And it is also true that bad feedback is better than no feedback. Anything could be helpful, it just depends on how we use them.

Reference

1.http://blogs.msdn.com/b/bharry/archive/2011/06/21/the-importance-of-feedback-in-software-development.aspx

2.http://forum.devolutions.net/topic1831-unexpected-error-while-installing-an-addon.aspx

3.http://www.gerixsoft.com/blog/innosetup/uninstall-feedback

Response to Article: “Architectural patterns for Mobile Application Development” by s1014475

This discussion is a response to the article “Architectural patterns for Mobile Application Development” posted by s1014475.

1.Background

The author mainly talks about two software design patterns: MVC (model-view-controller) and Layered Abstraction, which can be used for mobile application development in the article. The author also uses some mobile applications he developed as examples, explaining how specifically these patterns can be used in a real project. This post will discuss some points the author raised up in his article, giving some more thoughts on them, and at the end of the post, some more patterns which may also be suitable will be listed.

2. Discussion
At the beginning of his article, the author mentioned that mobile applications often require more user interaction compared to its desktop counterpart. The author thought the reason for that is “ (mobile application) usually waiting for an action from the user (such as a button click) ”, which seems not that sufficient. Actually, this point is quite important to the main topic of his article. The comparison between desktop application and mobile application can directly lead to whether a pattern that had been used for desktop application can be used for mobile application as well or not. It could be a good idea to have another session or paragraph talking about the similarity and differences between these two different kinds of applications. Besides, the reason the author gave is also kind of unreasonable, since desktop applications also require lots of responding from users, and more often, desktop applications has more complicated UI constructure. So, this point should be a similarity rather than a difference. And it will make more sense in this way to introduce MVC which has been widely used for desktop application development to mobile application development.

The author then introduced the MVC pattern. He used his own experience on some android application development as examples, which makes it really easy for readers to understand how MVC pattern matches with a project. The author also pointed out that, ”the suitability of MVC pattern depends on the context of the application in question”, which is a good point, just same as there is no silver bullet for software development in general, whether a pattern is suitable or not really depends.

The last point about MVC the author gave in his article is that MVC pattern fits his project well in the high-level overview, but not with closer inspection. The author thought that the definition of a widget in layout file and responding action in java file violates the concept in MVC pattern and then he gives a possible solution for this. However, the author does not make it clear whether it is impossible to fully apply MCV pattern in his project or it is better to use the combined pattern and why is the reason for that.

Then the author talks about layered abstraction. The author made good explanation abut Android system architecture, again, by using his own project as examples. To compare with and make the discussion complete, it’s better to gave some other sample applications developed in other systems, such as IOS and WM6. For example, figure 1 shows the IOS architecture, it’s similar to Android architecture(figure 2). There are two spaces, user space and kernel space. IOS system also has application layer and framework layer, exactly the same as Android. Media and Core Services layer provide the basic services such as graph, audio and video to the user, and these services pretty much has the same functionality as library layers in Android. Finally, core OS, the kernel space include drivers for the devices, it’s same in both systems.

From the comparison of these two systems, we know that most of the mobile systems has a clear architecture and layered abstraction. It is possible for a user to apply this pattern while developing their applications. The author did not mention it in his article, but the main advantages for this pattern is that it makes each component of the system independently, so that it supports large-scale, long-term development and maintenance. Each of the layers can also be reused for other projects. However, the main disadvantage is that when a behavior of a layer changes, it may cause cascades of changing behavior.

blog_2

Figure 1: IOS Architecture[1]

png;base6480a8f0bafa06de18

Figure 2: Android architecture[2]

Finally, except from what the author has introduced, lots of other patterns could also be used for mobile application development, such as: Command, Flyweight, Abstract Factory, Chain of Responsibility, Adapter and so on. Mobile applications has became a more and more important area of software engineering, and applying appropriate patterns while developing the apps will just make things more efficient and effective.
Reference
1.http://developer.bada.com/article/The-Basic-Architecture-and-UI-comparisons-between-bada-and-iOS
2.http://elinux.org/Android_Architecture

How to make Software succeed?

Introduction

When talking about software failure, most people will point it to software which failed to achieve their objectives either temporarily or permanently, or software which ran over budget. However, there also lots software failure due to the purchasing organization, such as poor requirements, overambitious requirements, unnecessary requirements, poor drafting, poor contract management, poor end-user training, or poor operational management. Except from those two main reason, sometimes software may also fail due to lots of other things, such as pressure from public opinion, competition with other similar products and so on.

Some unsuccessful software

Perhaps most people don’t know what is “Google Buzz”. It was a social networking, micro-blogging and messaging tool that was developed by Google before Google+ and integrated into their web-based email program , Gmail [1]. The project was launched on February 9, 2010 and discontinued one year later on December 15, 2011. Some media even regard it as one of the top unsuccessful IT product ever. However, what really makes Google buzz fail? There are two reason: The first and the main one was that people just regard it as a twitter clone with nothing improved, they have no reason to move from Twitter to Buzz; Another, and quite serious reason was that it had privacy concerns from the very beginning, people thought it leaks user’s personal information somehow by using user’s email.

google buzz

Universal Credit is another example. It is a new welfare benefit in the United Kingdom that will replace six of the main means-tested benefits and tax credits[2]. Unlike Google buzz which is a permanent failure, Universal is just a project with ongoing problems. However, the loss of it is just incredible, developers expected the total cost of it to be £2.2bn, whereas it cost about £12.8bn in fact, almost 6 times bigger, and that is just an estimated number. The main problem with Universal Credit was that The schedule has slipped. Only one of four planned pilots went ahead according to the original schedule, and this pilot was restricted to extremely simple cases[3].

universal credit

Maybe people won’t expect the famous video game Pac-Man to be a failing software project. However, it is. It was developed by Atari, and published in 192. Atari created 12 million cartridges, hoped that the success of the game can also help boosting their system sale. Pac-Man sold about seven million cartridges, the unsold units together with the expense of large marketing campaign just led to large losses for Atari. The over estimation of the game finally made Atari lost their prominent position in the home console market[4].

6081_pacman-cutters-on-black1

 Software failures& how to make software succeed

Concerning about the reasons that make software fail, there could be corresponding solutions to them. These solutions are not just invented today, but software still happened to fail from time to time. Bad management is common, just like there is almost no perfect program with no bugs. Here is part of those problems and their solutions:

  • Project run over time: Carefully design at the very beginning, make reasonable  schedule; Don’t  expect big jump between steps; Get the whole system working on time first,  rather than  spend tons of time working on a tiny component; Give up some  bad idea, before it is too late to do so.
  •  Project run over budget: Either estimate the time or the budget for a software  project can be relatively  hard. Just be realistic, make the budget based on the full requirements. Work  with team which has record of delivery within budget.
  •  Poor communication: “Never assume anything”. Always make sure that both of the people in the  team or the customers understand each other. Solve problems at the very  beginning, don’t leave it until it is almost impossible to change things.
  • Never reviewing project progress: Milestones could be the most helpful solution for this, challenges can be  overcome at each milestones, and stakeholders can be warned of delays and  changes to the products
  •  Inadequate testing: Leave enough time in the schedule for testing in the schedule. Regard testing  as important as  the initial development. In addition, even if product has  been released, testing can still be lasting at some point, before actually get  feedback or complain from the user.
  •  Lack of quality assurance: A few is not always better than nothing. Sometimes, leaving programs with  not completed documentation, or even worse, not completed implementation  will just spent whoever continues to work on it more time. People will  always prefer to writing their own code rather than reuse others’ confusing  code.

 

Conclusion

Software is not like anything other kind of products. It is probably the one which has the most failures. With day goes by, the competition between software developers has also become more and more intense. A good developer should not only be able to give attractive designs but also be able to manage projects properly, makes sure the project will neither run of time nor budget, the whole team understand each other from the beginning to the end, and tests are always adequate. Maybe not comprehensive, but this isreasonably be part of the answer for how to make software succeed.

References

1.http://en.wikipedia.org/wiki/Google_Buzz

2.Iain Duncan Smith announces the introduction of a Universal Credit

3.http://www.theguardian.com/politics/2013/oct/31/universal

4.Mikkelson, Barbara and David (2001-03-21). “Five Million E.T. Pieces”.Urban Legends Reference Pages. Retrieved 2006-07-20.