The Human Factor

1. Introduction

People are the most important asset in any type of project. The quality of the product is strongly dependent on the teamwork: “a good team builds a good product, a bad team builds a bad product” [1].

The main cause of a bad team is people themselves. It is usually enough for a single person to be bad to cause problems and reduce productivity. In this article I will discuss the concept of having a “bad apple” in your team and contrasting discussions and how to deal with them. I will also give examples from my experience I gained throughout my years of university.

 

2. Background

The “bad apple” concept refers to a bad fruit ruining all the other fruits next to it. In software engineering, this concept applies when the attitude of a team member affects the entire team such that the productivity decreases, problems arise and the quality of the product is jeopardised. In his article [2], Will Felps categorizes the types of human “bad apples” and suggests solutions of dealing with them.

He says there are three types of bad team members:

  • The withholder of effort: avoids doing work, does not complete tasks and does not take responsibilities
  • The affectively negative individual: always has a negative mood and attitude
  • The interpersonal deviant: proves disrespect towards his colleagues by having an inappropriate behaviour

Felps gives three ways to deal with these individuals:

  • Motivational interventions: upper management interventions or public criticism
  • Rejection: excluding from discussions and removing responsibilities
  • Defensiveness: revenge, good mood maintenance, distraction, denial and withdrawal from the group

It is possible that although the team doesn’t have a “bad apple”, diverse opinions can cause disruptive teamwork. In his article [3], Alistair Cockburn emphasizes how the difference and non-linearity between people have become an important factor when talking about application development. He presents fourteen concepts that summarize the human presence in a project. I believe that the most important facts that must be considered when assessing the success of a team are the following:

  • Trust in people to do what is necessary.
  • Adjust for people making mistakes.
  • People act according to their reward.
  • Recognise the presence of dominant personalities.
  • Let people work in unpredictable sequences
  • The communications load can soon dominate the project.
  • Software creation is limited by the ability of people to express their thoughts.

 

3. Experience

Throughout my university years I was part of a lot of group projects that aimed to teach us the importance of teamwork and organisational skills. However, no one actually instructed us how not to be the “bad apple” in our team. It is very likely that a lesson wouldn’t have helped us anyway since a lot of students would not have taken the advice. But in my opinion it would have at least made it easier for the good team members to confront and deal with the bad ones.

Every single team I was part of either had one or more bad apples in it or had people whose contrasting opinions lead to friction between colleagues. I have seen how the whole team has to suffer just because of one individual or how opposed attitudes put at risk the success of the project.

3.1 Slacker’s Effect

From experience I can say that in a university projects the bad apple usually comes in the flavour of “the withholder of effort”. Simply put, every team has a slacker. Such an individual can be observed as not attending the team meetings, bringing outsiders during the team discussions that distract everyone else or even find silly excuses for not being able to cope with pressure.

The worse thing about this situation is when you don’t see the bad apples from the beginning. Such an individual can be able to convince the team he is a hard worker and a good team player. The problem appears when you discover he is the exact opposite half way through the development time and adding more resources or removing people is impossible. In such cases disaster can be impossible to avoid.

The main effect of having such a person in my team caused “perceptions of inequity” between the other members. Everyone was comparing their contribution efforts with his and were considering the idea of being under-rewarded in the end. This can lead to the other team members to reduce their contributions and compromise the project themselves.

In a university environment, the motivational intervention by criticising the laziness to the supervisor would seem the most straightforward solution for such a situation. However, it doesn’t work very well since usually the supervisor does not take any action. I still don’t know if that’s because the whole point of doing a team project is learning how to deal with these situations (does this mean that the other solutions should be embraced?) or that the supervisor is too busy to get involved.

From experience, the best solution for such a situation is for the rest of the team to keep a strong relation. Having a good team leader can always help to eliminate interactions with the negative member and reassign responsibilities.

3.2 Diversity of People

I have also been in the unpleasant situation where the team had more bad members than good ones. Moreover, they were all good friends that didn’t take things seriously and were very reluctant in discussing each member’s responsibilities and taking advice from the others. I can’t put them in one of Felps “bad apple” categories since they were neither rude or with a negative attitude. With respect to their work, they finished in the end but the quality was very poor.

With only two of us left to do the rest of the work we realised immediately the seriousness of the situation we were in. Talking to the supervisor was not a solution since they were showing some progress on their work. We couldn’t possibly reject them either since they represented more than half of the team and the workload was too high.  We ended up fulfilling our tasks, keeping a positive attitude and hoping they will eventually finish the work they assigned to themselves. Disaster did strike us when our product failed to work during our presentation. Luckily we were given a second chance and my colleague was able to fix the bug caused by the bad members in time for our second demo.

This situation can be characterised by having team members with different attitudes and opinions with regards to work rather than having “bad apples”. Looking at Cockburn’s concepts, it was important for us to recognise the different personalities. We had to trust the others to do their necessary work and make sure that we can fix mistakes that might occur because of them. Moreover, if they wouldn’t have worked in unpredictable sequences or be able to express their thoughts in their own way the product might have not been finished at all.

 

4. Conclusion

In conclusion, every team will have a “bad apple” or occasionally more. Sometimes the “bad apple” might not be visible from the beginning and this could lead to problems later on in the development cycle. Other times, the “bad apple” effect is not very strong but differences between people’s personalities and attitudes can increase product creativity but also disrupt the teamwork.

Felper categorised the ”bad apples” and solutions against them in his article while Cockburn emphasises the importance of non-linearity between people. In both cases it is important to know how to deal with that particular situation. In a university environment it is very likely to encounter such situations while being part of group projects.

 

5. References

[1] Edwin Dando, “Behaviour Dynamics in Agile Teams”, July 2013

[2] Will Felps, “How, When and Why bad apples spoil the barrel: Negative Group Members and Dysfunctional Groups ”, 2006

[3] Alistair Cockburn, Growth of Human Factors in Application Development”, 1995

Just one step before Design Patterns: *Micro Patterns*

1. Introduction

It has always been a good question to ask: “How to trace the design of a program?”, The most obvious answer is to trace the design patterns. Finding design patterns in source code is hard, so researchers are trying to find simpler patterns to trace. The main idea of this blog post is to define “Micro Patterns” which are one-class design patterns, and talk about their importance and how they are related to SAPM. Micro Patterns are midway between simple structures and design patterns! Let’s see 🙂

2. Patterns! Patterns! Patterns!

In the SAPM course[8] we had a lecture about “Design Patterns” and another about higher-level patterns called “Architectural Patterns” followed by another lecture about an important example of Architectural Patterns which is Scripting Components. I have also seen that there are many blog posts my colleagues posted about these patterns!

2.1. Hey! Do you remember what design and architectural patterns are?

RECAP: Design Patterns are approaches and solutions for problems occurring repeatedly in object-oriented software development [1]. They provide a shared vocabulary and ease the communication between developers. Design patterns are template solutions [2] that might contain one class (such as Singleton) or ,most-of-the-time more than one class (2,3..or more). Architectural Patterns care about the whole project, not specifically to a problem. The aim is to build reusable components [3].

2.2. Allan, SPAM and the big step!

Allan
I want to go back to SAPM lectures. Allan stated that developers solved the idea of reusability in small but not in large-scale projects. Just go back to the first slides of the Design Patterns lecture [4] and check how we started from finding simple patterns in codes (e.g. how developers patterned the looping idea as a “for” structure). I felt that there is a dramatically big step from finding simple patterns that led to defining structures like (loops, methods, classes,…etc) to finding higher-level patterns like the design patterns. Don’t you think the same?
This idea reminds me of a paper I once read and it talked about what they called “Micro Patterns”!

2.3. Ok? So isn’t it enough we have all these types of patterns! You want us to have more?!!

Simply… YES!!!! Most of design patterns contain more than one class and it is really HARD to find patterns in more than one class. My research review last semester was about finding patterns in source code and i found that it is difficult to find patterns in one class so how about finding patterns among several classes?

2.4. So?

Simply, I think we should work to find some simple patterns and then work to find some more sophisticated patterns. I am not saying that we CAN’T find these complex patterns immediately. Some people have already done so but as Mak, Choy and Lun[5] said, “. . . automation support to the utilization of design patterns is still very limited”.

3. Finding Patterns in Source Code! What is this?

Finding patterns in source code means searching for interesting information and structures in the code. The aim is to detect similar code fragments in source code. Finding these patterns has many applications such as bugs detection, code quality determination , and refactoring. Although the machine learning (ML) techniques and natural language processing (NLP) algorithms are mostly developed by researchers in the field of computer science and artificial intelligence, they are not used that much to solve the problems of informatics itself. Using the ML and NLP techniques to find patterns in source code seems an interesting field as it seeks to solve the problems of informatics by using tools developed by people from the same field.

3.1. ok! But What are Micro Patterns?

As stated in the introduction, It has always been a good question to ask: “How to trace the design of a program?”, The most obvious answer is to trace the design patterns. Many systems do this but with low precision and high error rate. Some researchers suggested looking for other patterns which are traceable and less abstract [6, 7]. The term “Micro Patterns” is used to represent the class-level traceable patterns. Finding these patterns has a great influence on Software engineering as they might help in using more efficient design, code reuse, and automation.
Finding patterns in a source code is extremely useful, but can you use these techniques to generate new patterns? Answering this question is somehow hard as we need new ways to let our algorithms understand the object oriented programming fundamentals such as the inheritance and polymorphism.

3.2. Wait a little, I googled “Micro Patterns” and didn’t find much results!

Well, I did too! While some people consider these patterns as a kind of design patterns since they aim to create a sharable vocabulary in addition to the previous advantages, the term is mostly used by people working in the field of source code mining to refer to one-class patterns they want to find!

4. Conclusion

Well, I think, and as stated in SAPM lectures, reusability in small projects is solved by defining structures but we still need to formalize the solutions for higher-level larger-scale projects. Micro Patterns are somewhere in the middle between simple structures and higher-structures. Searching for them and using them will have lots of advantages.
Micro Patterns are one-class design patterns that are easier to find and therefore to be formalized. They have the advantages of design patterns as they are types of them beside the benefit that they are easier to find.

Note: I didn’t want to fill the blog post with names and descriptions of micro patterns since my aim was to introduce the Micro Patterns without drowning in their details. People interested in getting more details about the topic are recommended to read the paper “Micro patterns in Java code”[7].


References
[1] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/391
[2] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/485
[3] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/486
[4] http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/Design_Patterns_Lecture_Start
[5] Jeffrey K. H. Mak, Clifford S. T. Choy, and Daniel P. K. Lun. Precise modeling of design
patterns in UML. In Proc. of the Twenty Sixth International Conference on Software Engineering
(ICSE’04), pages 252–261, Edinburgh, Scotland, United Kingdom, May 23-28
2004. IEEE Computer Society Press.
[6] Balanyi, Zsolt and Ferenc, Rudolf, Mining design patterns from C++ source code, International Conference on Software Maintenance, ICSM, pages=305-314, IEEE, 2003.
[7] Gil, Joseph Yossi and Maman, Itay, Micro patterns in Java code, ACM SIGPLAN Notices, Volume 40, Number 10, pages 97-116, ACM, 2005.
[8] http://www.inf.ed.ac.uk/teaching/courses/sapm/

Viewing risks in IT offshore outsourcing from an unsuccessful software project

Introduction

Offshore outsourcing refers to a model in which the service provider and outsourcer are in different countries, they collaborate to complete the project. There are two major offshore outsourcing categories: IT outsourcing and business process outsourcing [1].

As for my point of view, three major risks in IT offshore outsourcing are misunderstanding others’ intention which resulted by culture or language difference, lack of communication and feedback is delayed. But these risks can be reduced by taking advantage of modern technology like audio/video conference or sending skilled BridegeSEs to development site, and using agile development. In this article, I will talk about the risks and solutions based on my own experience in an unsuccessful offshore outsourcing project.

What was my experience about?

When I was working in a software development company as an intern, my team was developing a project outsourced by a Japanese company. The requirement analysis process was finished in Japan by the outsourcer. My team was responsible for designing, coding and testing.

Before I left, my team delivered two versions to the outsourcer. We thought we finished the project because all the functions were implemented. However, the Japanese company was unsatisfied with it. They thought we did not understand the intention of the software and what we developed had great difference with what they thought should be.

How did the disaster happen?

Let’s first talk about the project requirement. I do not think it was a good one. The document did not provide much detail for some of the functions but only said what functions the system should have. Besides, the requirement document did not clearly specify the reason for developing this system nor the value that the system could bring to users. As a result, our team did not understand the requirement document clearly.

We understand that it is hard to write a perfect requirement document. Document authors and the developers might have different knowledge background and development experience. What the authors think they have clearly stated might be confusing to or misunderstood by developers.

Communication seems to be a good solution to this problem. Authors and developers should discuss about the requirement effectively, minimize the difference in understanding the documents and make it a completed one by adding some detail.

However, in this case, we did not communicate with the authors effectively. The authors who wrote the requirement document were in Japan while we were in China. We did not communicate directly, not to mention to have a face-to-face one. After we read the requirement document, we wrote a list of questions that we were unsure of and sent it to their Bridge Software Engineer (BridgeSE) in Japan.

BridgeSE is a popular position in some Japanese outsourcing companies. They know both Chinese and Japanese. BridgeSEs act as the interface between outsourcers and service providers. They negotiate with outsourcers about project issues, analyse the requirements and answer development team’s questions related to the projects.

In our case, BridgeSe answered some questions based on his own understanding, and forwarded the question list together with his own answers to the authors who wrote requirement document. The authors answered remained the questions and confirmed or modified the answers provided by BridgeSE. Then BridgeSE sent the answer back to our team in China. Before we delivered the first version, we discussed about the project only once.

Next stage was analysing, designing and developing. Our team delivered the first version which contained only user interface (UI) but did not implement much function. Since the description of UI requirement was specific, there was not much problem with the design. As the functions were not implemented, the outsourcer did not have the idea whether we understand the project in the same way as they did.

After that, we implemented the functions according to our understanding and delivered the new version to the outsourcer. We thought we implemented the functions, next, we need to test. But for the outsourcer, they realized that our design was not what they wanted.

The development team negotiated with document author about project requirement only once, not directly but via another person, and this process took two weeks. Besides, we delivered only two versions to the outsourcer. There are several problems with this development process.

First, all communication was by sending emails, some ideas might not be properly expressed or correctly understood. In this case, the outsourcer and development team were from different nations, there was great difference in language, culture and custom. These factors would bring difficulties to communication and understanding. If a project is designed by outsourcer and coded, tested by service provider, the trouble brings by ineffective communication would not be that serious because development team could coding according to the design. The design usually provides elaboration of functions, software framework in UML, class diagram, activity diagram, etc. These are like a blueprint and development team can implement exactly as the design describes. However, if the service provider needs to design as well as developing and test. The two sides need to discuss about the requirement in detail because they may have different understanding toward a same thing. If both sides depend entirely on document, or do not have face-to-face or audio discussion, the result might be a disaster because of the difference in how they understand the written document.

Second, our team still had some questions over the answers, but we did not negotiate with the BridgeSE because the expected time to deliver the first version was six weeks. The communication took a long time and we did not think the remained four weeks was enough for development. We designed as we thought would be right.  But in fact, the outsourcer was not satisfied with our design.

This problem was mainly resulted by inefficient communication, feedback was delayed for too much time. Instead of writing emails, we can take advantage of modern technology and use better ways to communicate. For example, audio conference, video conference, etc. These are ways that enable two sides to communicate as if they are face-to-face. Even though they are thousands of miles away, questions can be responded immediately.

Besides, the development methodologies our team used was not appropriate. We should use agile development [2]. To be specific, instead of just delivering an UI and an almost finished version, we should deliver in a short period of time or as long as we implemented some functions. Then we need to adjust according to the outsourcers’ responding. The new technology like web-based applications already enables us to set up demonstration system and explain our design to the outsourcer. If we use waterfall development [3], chances are that service providers may think they understand but actually they don’t. They have to redo the whole phase like designing entirely, this wastes time and cost.

Third, as document authors do not come to the development site or conduct a video conference and explain requirement for service providers in most of the Japanese offshore outsourcing projects. BridgeSE is a very important role. They discuss with authors about the project so that they will have almost the same understanding on the requirement as the authors do. Then they answer questions to development team as soon as possible. However, in this case, the BridgeSE did not seem to have enough understanding about the requirement and the discussion process consumed too much time.

This problem could be avoided from two aspects. First, Japanese company should hire BridgeSEs with sufficient development experience. BridgeSEs should be trained about the project and obtain enough information about it, so that they could answer the questions accurately. Second, BridgeSEs should be on the development site or at least communicate every time face to face by video conference.

Conclusion

The original purpose for IT offshore outsourcing is to reduce the development cost. But there are risks like they misunderstand the other’s intention, they do not communicate a lot, the communication is not effective, or the feedback is delayed. These risks might lead to the failure of the project or the raise in cost.

For both service provider and outsourcers, it is very important to agree on an efficient communication way so that time is fully used. For outsourcers, they should hire experienced BridgeSEs who have no barrier understanding language of the two sides and train these people to be familiar with the projects, and BridgeSEs should also be on site or at least respond to the questions in short time. For service providers, they should use proper development methodologies like agile development and deliver versions to outsourcers frequently, so that their product could meet outsourcers’ requirement.

Reference

[1] Aundhe, M. D., & Mathew, S. K. (2009). Risks in offshore IT outsourcing: A service provider perspective. European Management Journal27(6), 418-428.

[2] Thomas, D. (2005). Agile programming: design to accommodate change.Software, IEEE22(3), 14-16.

[3] Petersen, K., Wohlin, C., & Baca, D. (2009). The waterfall model in large-scale development. In Product-Focused Software Process Improvement (pp. 386-400). Springer Berlin Heidelberg.

Large-scale projects and their possibility of failure

Introduction

Since IT specialists started working on projects they had to face the possibility of failure. According to their scales they could be separated in three categories: small, medium and large scaled.Even if in all of them failure was always extremely possible to happen, in large-scale projects it was much more possible than in the other two types of projects.

Below, there are the reasons of this phenomenon analysed and, finally, there is a discussion about how developers could avoid it.

1 out of 9 succeed

Frederick Brooks does a very vivid comparison in his book called “The Mythical Man-Month”[2]. He compares the large-scale projects with pre-historical beasts that are inside a tar pit and struggle and fight back in order not to sink. However, it is well-known that as someone fights to avoid sinking the more he sinks.

It is a matter of fact that, nowadays, the structure of the large-scale projects has changed a lot as far as concerns simplicity. The needs from a project have become more and the developers must create constructions that are more complex and produce results that have nothing to do with past project efforts [1]. According to a UK study only 1 out of 9 large-scale projects finally succeed  and because of large-scale system failure the cost is more than one trillion dollars worldwide [3].

Why does this happen?

There are many reasons that can occur failure. Firstly, the most important is complexity. In company systems today, there are millions of computers used by people all over the world who are using the same network in order to write code and work on the same project. It is normal that one wrong life of code can cause serious problems [1]. Furthermore, as bigger as a project it is more difficult to separate it into tasks, because of the fact that it is not so easy the tasks to be divided and be equal in difficulty.

Secondly, over-optimism is capable to lead to failure. Large groups with many good programmers make the inexperienced feel confident and the experienced ones are under pressure and have to accomplish a plan that is not so realistic as it is described by the customers[1].

Furthermore, the final part of a project is the testing. Because of delays, testing is usually a mis-scheduled part and the product is not really tested in order to be ready to be delivered to the customer. Finally, another reason of failure is that in large and complex projects customers do not really know how to say what they want. They are not programmers and I believe it is really acceptable. However, they should be open-minded and try to understand and the programmer and try to think in the way he does [1].

How to avoid? – Discussion 

The first think that should be done is to simplify as more as possible the project in order to  avoid complexity. Research and estimation of complexity are probably the best ways even  if it is understood that it is difficult to measure complexity  from the beginning of the project. It is known that companies do not pay so much attention to testing. However, this is an important way to avoid failure because of the fact that in testing it is the first time that the program really runs and bugs that before were priceless after the testing might look really big [1].

Although, in my opinion, it is also important to build a team that is able to focus on the real targets, understand the capabilities and not overestimate them. The team leader must, also, inspire the team and make them do anything that it takes to follow the schedule. IT industry should also work more on finding new methods that could be used in order to be able to follow the new needs and expectations.

Conclusion

As the information technology is being evolved day by day the amount of demands is getting larger and larger. Projects are now much bigger than they used to be and companies are trying to produce the best possible result. However, most large-scale projects fail. There are may reason why this happens. Although, it is significant for the managers to understand that the creation of software has become very complex and failure is not that amazing. I believe, that, the keys to avoid failure are the stuffing of a very good team, which does not include only experience, but also responsibility and good communication and the understanding of the importance of testing.

References

[1] Denker, Ahmet. “The Challenge of Large-Scale IT Projects.” World Academy of Science, Engineering and Technology 9 (2005).

[2] Frederick P. Brooks Jr. – The Mythical Man-month: Essays on Software Engineering – Chapter 3- 1975

[3] Dalcher, Darren, and Audley Genus. “Introduction: Avoiding IS/IT implementation failure.” Technology analysis & strategic management 15.4 (2003): 403-407.

How to find underlying reason from user feedback to make your software better

1. Introduction

Everyone knows the importance of collecting user feedback of your software product. The simple reason is that user feedback reflect their satisfaction and user experience of your software product, and these can have big impact of sales of your software product.  Many software products failed because their developers have not done a good job of collecting useful feedbacks from their users. This article is going to talk about different ways to collect user feedback, analysis the advantages and disadvantages of these ways, and how to improve the effect of user feedback. I will propose some ideas to help us find underlying reason from user feedback to make our software product better.

2.Existing ways to collect user feedback

2.1 Using feedback form

The most common way to collect user feedback is feedback form. Companies post some questions on their mobile phone applications, websites and so on.

Figure 1. Mobile Feedback Form [1]

44.png

Figure 2. Website Feedback Form [2]

Advantage of feedback form is that it does not cost much money and you can collect feedback directly from your existing user. Disadvantages of using feedback form are very low rate of collecting user feedback. Although some companies try to use some reward to attract their users fill in their survey, this method can lead to another problem. Many users just fill in their survey very quickly and randomly to get the reward, this can make the result of feedback forms wrong and cause the company greater losses.

2.2 Using third-party service

Some company uses third-party service to collect users feedback. For example, Google Analytics[3] is one of the best free analytics applications for getting basic traffic and visitor data. You can use Google analytics to monitor the user’s activities of your website or mobile apps every day, such as number of visit, where your users from and so on.

Advantage of using third-party service to get user feedback is that you can get every user of your software product anonymously, and the result of the feedback is more reliable.  The disadvantages are you need to pay extra money if you need premium service, and service can not be customized by yourself if third-party company does not provide this service. Of course, data security is another issue you have to consider.

2.3 Eye tracking technology

Academia and business have big interest of eye tracking technology. Eye tracking is used in research as a means for insight into human behavior [4]. For example, Tobii Mobile Device Testing [4] solution lets you study how users experience mobile websites and apps or how they consume mobile ads on mobile devices and tablets [5].

55.png

Figure 3. Mobile Device Testing by using eye tracking technology[5]

Advantages of eye tracking technology include it is a very trendy technology and the future development of this technology are very broad. Disadvantages of eye tracking technology include it just give you answer of what area users are watching, but it does not give you why user look at this area. Correctness of this technology should be tested and verified.

3.How to find underlying reason from user feedback

One challenge of collecting user feedback is that we need to make sure the representativeness and accuracy of data. When we ask our old users why they are no longer use our software product, they always use “no time” and “no money” as a reason to get rid of us, but the real reasons are always unknown.  How could we know it is the real reason that our user like or dislike our software product? We need to find underlying reason instead of superficial reason from user feedback.

3.1 five why’s

Five why’s is invented by IDEO [6], which is a global design firm that takes a human-centered, design-based approach to helping organizations in the public and private sectors innovate and grow. Idea of this five why’s method is very simple: asking your user five questions about an issue continuously to get the deep and progressive answer, and this method allow your user express their deep thoughts and reasons. Here is an example of five why’s method from IDEO as follows, and this example shows the true reason of user exercise:

6.png

Figure 4. an example of five why’s method from IDEO [6]

When we test our software product, five why’s method can become as follows:

 
Game developer: “Why don’t you log in our  game?”
User: “I have no money and no time.”
Game developer: “Do you play other games which are similar to our game recently?”
User: “Yes, but I am not very interested in it.”
Game developer: ”What kind of game you like now?”
User: ”I guess some sports game.”
Game developer: ”Why you like sports game now?”
User: “I feel very exciting when I can create my own role in the game, and I feel myself play in the court.”
Game developer: “What differences do you think between our game and sport game?”
User: ”I think the sport game soundtrack are much cooler than your game, their 3D effect really exciting and I can play with my friends online. Your game does not have these functions.”

After these five question, game developer finally find the real reason of user does not play their game.  User play other games because they like better game soundtrack, visual effect and multiplayer game.

3.2 Behavior Analysis

When we use user feedback survey on the internet, it is difficult to ask questions to get deep reason. It is hard for user to answer the why they behave like this instead of that, but it is easier for them to answer with their behavior. Furthermore, it is more reliable to answer questions about behaviors. There are some questions we don’t need to ask our users directly to get the deep reason, instead, we can just analysis their behaviors to get the underlying reason.

3.3 Indirect comparison of other related products

Sometimes users are unaware of the real reasons behind their actions. We may not get specific reasons if we ask questions directly. So we can use indirect comparison of other

related products to inspire users to dig out the underlying reasons.

I will show you an example as follows:

Interviewer: why don’t you use our premium service?
User: “I have no money.”
Interviewer: “Are you still use other premium service?”
User: “Yes. I use premium service from X company.”
Interviewer: ”Why you use X company’s premium service instead of our premium service?”
User: “Because I think their service are more useful, and I have more privilege.”
Interviewer: “What privilege? Could you give us an example?”
User: “Unlimited downloading”

This use case shows us it is not because user have no money that he does not use our service. It is because our premium service is unattractive to users, and user want unlimited downloading privilege.

4.Conclusion

In this article, we talked about different ways to collect user feedback which are used by today’s technology company. However, after analysis these different ways, we find they all have their disadvantages. So we proposed some ideas to improve the accuracy of user feedback to make the result more reliable. These ideas could be rules to follow in the future if technology company want to design their method to collect user feedback. These ideas can help software company find the underlying reason why or why not the user like their product, and these more reliable user feedback could be guidelines to follow if they want improve their existing product or develop new products.

Reference

[1] Mobile Feedback Form. 2014 Neemware Inc.

http://www.neemware.com/products/mobile-feedback-form/

[2] Preparing for a Site Redesign. March 20th, 2013. Bourke Design.

http://www.bourkedesign.com/2013/posts/preparing-for-a-site-redesign/

[3] Google Analytics. 2013.

http://www.google.com/analytics/

[4] Tobii. 2013 http://www.tobii.com/

[5] Tobii Mobile Device Testing Solution. 2013 Tobii Technology.

http://www.tobii.com/en/eye-tracking-research/global/products/solutions/mobile-device-testing/

[6] IDEO http://www.ideo.com/uk/

Game Development as Software Development

1. Introduction

Game development is a collaborative art. Creating games require many teams working together in drawing, choosing music, writing scenario and programming!
This blog post aims to compare game development with the general software development in order to find the best methodology for game development. While most applications are service-oriented, games goal is to entertain users. Since there are some differences between games and software, there will be some differences in the development process. Will traditional project management techniques work with games? What about waterfall and agile methods? Let’s see!

2. Games Development

2.1. Video Games VS. Software

video-games-132
Nintendo…the world’s largest video game company by revenue

A video game is an electronic game that involves human interaction with a user interface to generate visual feedback on a video device[1]. There are several types of games such as casual, educational, and serious.
Video Games are just like any other computer program in terms of intangibility. However, there are some differences. We usually create applications to provide services. Microsoft Word for example is software to create/edit/print textual data! However, the main aim of games is to provide some “fun”[2]. Games are created to entertain users! Even if they are educational, the goal is to teach the user while he is having some fun.

2.2. Game Development VS. Software Development

Video game development is the process of creating a video game[3]. Just like any other software development there are plenty of methodologies we may follow. Games are, most of the time, large-scale software. In game development there are several teams working in the same project. There are teams for programming, drawing, designing..etc. Games include audio, video, images, and a scenario. Another important thing to consider is the “experience” we aim to create and evolve in games[2].

GD1_B
Many teams work together to build a successful game

In “Probabilistic Modelling and Reasoning” course[12] we learnt that one of the hot topics in machine learning now is how to match players with similar skill levels in a large online gaming site[11]. It is about “measuring” experience of players! Or measuring experience of one player in order to let him play with a difficulty-level that matches his experience!
Game development is not just about programming! It is a creative work! We learnt that a piece of software is considered a successful one if it is delivered on schedule, within budget and meets users’ needs in scope and quality[4]. A good question to ask here: “What are users’ needs for a video game?”. In lectures we discussed how hard it is to measure software! It is even harder to measure how fun a game is! Or How entertained the gamers are! We studied some measures for software but here the measurements are harder since game development is driven by innovation.
Sometimes we have the time limit. For example, a game for Christmas should be published before Dec.25th!

2.3. Choosing the Methodology

Game development is a software development process[3]. Some people say that game development is not suited for typical software life cycle methods, such as the waterfall model[5]. Waterfall is a hated process especially in games[7]. Some developers say it is not practical because creating fun(user needs) is an experimental process. Building software iteratively by separating it into small deliverables and working on tight timeframes seem more reasonable for some developers[7]. However, some others believe in creating a balance[6] between the agility and the waterfall approaches. Game development involves an overlap of many methodologies[6]. When we have clear requirements and specification we can use waterfall but the design will be iterative[5].

2.4. Personal Opinion

Assassin's_Creed_Revelation_Development_team
Assassin’s Creed Revelation Development team

In SAPM lectures[10] we studied that it is important to use the formal traditional project management charts and methods when there are tasks with complex dependencies. I believe that there are higher dependencies in game development than any other software. There are high numbers of people working together in a tight-connected tasks. Artists should finish drawing the characters in the game in a specific time. Programmers can’t do some tasks without having some images and audio files. In game management we need to use the traditional techniques for the whole project. Contracts and assets could be written waterfally. However, we still need to use some agile methods for the design. Successful games projects are delivered on time, within budget, and they should entertain the users. Finding the balance in using the methodologies is a core key for this.

3. Conclusion

Games are just like any other software in terms of intangibility. However, games are more complex in terms of having multiple teams working together with complex related tasks. The goal of games is to entertain the user. The best approach for game development is to use a mixture of methodologies starting from formal traditional techniques to deal with the whole project, to waterfall method in writing contracts, till agility in programming!

Recommended Video (less than 3 minutes)- The Evolution of PC Games
https://www.youtube.com/watch?v=OuO-s1kugLs

References
1. http://en.wikipedia.org/wiki/Video_game
2. http://informatics-sapm.blogspot.co.uk/2013/03/video-game-production-different-kind-of.html
3. http://en.wikipedia.org/wiki/Video_game_development
4. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/6
5. http://gamifique.files.wordpress.com/2011/11/11-game-design-second-edition.pdf / page 225
6. http://www.gamasutra.com/view/feature/181992/waterfall_game_development_done_.php
7. http://www.whatgamesare.com/waterfall-development.html
8. http://www.whatgamesare.com/agile-development.html
9. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/305
10. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/108
11. http://www.kaggle.com/
12. http://www.inf.ed.ac.uk/teaching/courses/pmr/lectures/beliefnetworks-print.pdf – slide 2

Pictures:
1- http://www.beachbayonet.com/wp-content/uploads/2014/03/video-games-132.jpg
2- http://assassinscreed.wikia.com/wiki/File:Assassin%27s_Creed_Revelation_Development_team.jpg
3- http://www.e-games.tech.purdue.edu/images/GD1_B.png

We do not need Design Pattern, we need the concept

Design Patterns are getting popular in recent decades. Most of the employers would ask questions about design pattern in the interview with applicants. It seems to be an essential skill that software developers must have to find a good job. Most of the companies are more or less using some of the design patterns in their products because it can bring them huge advantages. However this article tries to explain that design patterns are not almighty and understanding the concept behind design pattern is more important than knowing how to apply them.

Why to use design pattern

Software usually consists of tens of thousands lines of codes. Code consists of two parts, data structure and algorithm to implement some functionality. Software also consists of two parts, codes and design pattern. A complete software will integrate those small pieces of code to make them work together and this how would different piece of code be organized and designed to cooperate to deliver a complete system is a reflection of design pattern. For the same problem different people may have different ways to organize their code,logic to solve it. Design patterns are reusable standardized solutions to typical problems that frequently occur. They have proven to be the optimal approaches to solve specific problems.Apply the existing design pattern means one does not have to work on a problem that has been already solved by others. Also design patterns are useful in creating a shared vocabulary in a large team[1].

It’s very hard to use design patterns appropriately

Even though we can benefit from applying design patterns in our projects, it is very difficult to use them appropriately. People are very likely to fall into a trap that they want to use a design pattern not because it can solve the problem but simply because they can use it. It happens a lot to novice developers who fell in love with design patterns because of the beauty of the excellent design or obsessed with the feeling that they are being professional. This attitude will normally lead to abuse of design pattern. Applying the wrong pattern or needless pattern will unnecessarily increase the complexity of the code and increase the cost for testing and maintenance etc. Also there are criticisms on design patterns saying that the emerging of design pattern is a sign of lack of corresponding feature of programming language/framework. For example the Singleton, can totally be replaced by developing a new feature of any programming language to ensure there is only one instance of given class.

What do we actually need from design patterns?

As I mentioned in above section, sometimes developers use design pattern even when they do not understand why they are using it. Then it comes to the question that when to use the design pattern or what do we get from design pattern. To me it is the concept behind patterns which is important rather than the actual patterns. When it comes to the real software development, chances are the real problem we are facing usually is very complex and do not fit with any single existing pattern. With the knowledge of concept behind the patterns, we can accordingly modify/combining the existing design patterns to cater to the specific requirements. Design patterns are like a set of screw drivers of different shape and size. We need to know how to create one rather than how to use one because the bolts’ size are all different. We may find a suitable one but not a perfect one.

It is not all about design pattern

Software is not all about design patterns and there are lots of other things we need to take into account, for instance performance,maintenance cost and testing etc. Sometimes applying a design pattern can create decent and clean code but we may need to sacrifice for other reasons. For example, if you are developing a web-system to generate analytical chart for users. You may want to apply a template pattern to achieve a better code re-usage, which means code on the server side to generate the chart and only return the chart to client. However in reality no people would do that because the server has to do the work of both filtering data and generating charts. That will increase unnecessary burden on server. One would possibly do is to put the presentation on the client side code, so the server only need to filter data and let the client side to generate chart based on the returned data. This would possibly lead to some duplicate codes but it is necessary cost to achieve better performance.

Summary

In this article I have shortly describe what is design pattern and its advantages. Then I tried to convince the readers that it is very hard to fully understand design patterns and apply them appropriately. Furthermore I made the point that what is valuable to us of design patterns is its concept. Understanding of the concept is required to avoid abuse of design pattern and to make more reasonable design given a specific requirement. As a conclusion, it is good to know design pattern but do not attach to it. It is just a set of general approach to certain problems, not a big deal. Do not treat it like something you can show off then it will be very useful.

References:

[1] Allan. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/415

[2] Design Patterns wiki page. http://en.wikipedia.org/wiki/Design_Patterns

[3] The pros and cons of adopting and applying design patterns in the real world. M.P. Cline. Communications of the ACM, 39(10):47-49, October, 1996.

[4] Design Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, and Vlissides 1995, Addison-Wesley, ISBN 020163361X.

 

A Foolproof Formula For Success?

Description of the Problem

This post will analyze and describe the most prominent issues and problems that result in the failure of software engineering projects. In 2004, only 29%[1] of projects were completed successfully, motivating the study to figure out where the problem lies and what can be done about it.

Success in a project primarily revolves around the satisfaction of the client. However, if it not up to their judgment, when broken down, a successful project is one that is completed on time, within budget and meets all the requirements as specified in the design. Even small botches in any of these aspects could constitute a failed project.

A project can be classified in one of two ways; challenged and failed. A failed project is one that does not work, or has been cancelled. A challenged project has less brutal pitfalls, i.e. it was over budget, over schedule or has not implemented all of the necessary functionality.

The question then remains, what are the biggest troublemakers in software engineering projects that make their success rate so low and is there a foolproof way to ensure that a project will be a success?

 

Cause and Effect

The first thing I would like to discuss is what happens when there is an absence of leadership within the team, creating many problems in numerous aspects of the project. This would include a lack of direction with regards to design and planning for the project, potentially resulting in time wasting or the project going over budget. You need someone to make decisions should the team get stuck as well as someone to be able to manage the team and make sure all the members are doing their job and doing it right. It is also important that the leaders ensure that each and every worker understands exactly what it is that they are doing which is just as important and the leaders understanding exactly what it is the client wants.

Secondly, it is vital that a business case for the project has been made before the project has begun. This aims to measure the likelihood for success financially. If the return on investment is less than the cost to create and maintain the software, it is not worth doing. There is also a delicate balance that should be made between quality and budget. This means that an estimate building cost must be calculated at the start, and bad estimating techniques can also be a hazard for any project.

However, accountability is not solely on the leaders and managers should the project not be a success. Having personnel that are talented, get along well and work hard will significantly increase the chances of the project being a success. Therefore, hiring a team of well-trained and enthusiastic individuals will certainly increase the chances of the project being a success.

The next potential hazard is poor or non detailed design. Not having a clear, outlined plan from the beginning is setting the project up for disaster. This could result in certain requirements being forgotten. It could even be that the project moves completely out of focus and time is spent working on functionality that is completely irrelevant to the problem at hand. The functional and non-functional requirements need to be gathered and understood as well as any other constraints. Constraints could include aspects such as what technologies are available or what integrations are necessary.

Another potential concern for failure could occur when using external software not produced within the project. This could result from members wanting to use the newest technology on the market that has perhaps not yet been tested thoroughly enough. In reverse, perhaps by not having enough money in the budget to purchase what you need, therefore having to rely on mediocre alternatives. Any time that third-party software is used; the project runs the risk of running into some problems.

Unexpected problems, whatever they may be, may arise that could cause some failures. You cannot predict or plan for every scenario and sometimes a disaster may not be in anyone’s control or of anyone’s doing. This could include things such as the client changing their mind on requirements, benefactors pulling out their funding, or even natural catastrophes that physically damaged all at the work that had been done until then.

 

Personal Experience 

            When I have worked on a software engineering project, the success or failure of it usually relies on how hard the team or I have worked on all the aspects mentioned above. Making decisions about the design at the start was always extremely important and useful, as was having a leader to take responsibility should there be a conflict to make the decision themselves. Therefore, from my individual experience, I believe that design and leadership are the two most essential factors to aid the success of a project.

 

Conclusion

            From the points and descriptions as stated above we can now try and summarize the closest to foolproof formula for success that exists in a software engineering project.  Each aspect is an important piece in the project puzzle as can be seen in the graphic below.

SAPMimage1

Unfortunately, even though the project management style might adhere to all of these factors as best as they can, issues out of their control may still arise and lead to problems.

There are many reasons why a project can fail, some are unavoidable and some can have their likelihood of occurring reduced with proper planning and evaluation of every aspect of the project. A foolproof formula for success does not seem to exist but the team can try and minimize the risk in the areas outlined that cause the most problems.

 

References

[1] Comelio, P. (2008). Why Do So Many Software Projects Fail?. Available: http://www.slideshare.net/PhilComelio/why-do-so-many-software-projects-fail-25nov2008. Last accessed 7th March 2014.

[2] Connell, C. (2010). Why Software Really Fails And What to Do About It.Available: http://www.drdobbs.com/architecture-and-design/why-software-really-fails-and-what-to-do/223700002. Last accessed 7th March 2014.

[3] Outspeaking. (2014). Why Do Government IT and Software Projects Fail?. Available: http://outspeaking.com/words-of-technology/why-do-government-it-and-software-projects-fail.html. Last accessed 7th March 2014.

Semantic data types

Back in 2005 Joel Spolsky wrote a blog post about Making Wrong Code Look Wrong.

Joel’s basic argument is that programmers should look for conventions that make incorrect code stand out, or look wrong. He goes on to argue that Applications Hungarian.aspx) notation is a good thing as it confers semantic information about the variable.

As an example he gave used the Microsoft Word code base. The developers had added prefixes to variables such as xl being horizontal coordinates relative to the layout and cb meaning count of bytes. This trivial example seems to make a lot of sense, as it makes it easy to see that there is no way that xl = cb should be allowed to happen.

Taking a more complex expression, and it starts to involve more thought and become less clear and requires memorising an increasing number of prefixes. Seeing code such as (pcKesselRun/msFoo)/msBar could quite conceivably lead to a thought process such as: Looks right, but why is Kessel Run in parsecs? Is that a typo? I can’t remember what ms is. I assume it is milliseconds but I am sure someone used it as meters/second somewhere.

With more modern languages shouldn’t there be a better way?

Types to the rescue

The concept of Applications Hungarian notation surfaced (according to Wikipedia) in around 1978 when fewer languages allowed user defined types. Modern languages with better type systems allow concise definitions of types and operators. Code then doesn’t just look wrong, the code fails either to compile or to run.

Once the type system is used to represent the semantic type of the variable, it removes a lot of the ambiguity and chance of making mistakes. In treating everything as real numbers type conversions are almost always valid

(pcKesselRun/msFoo)/msBar => (real/real)/real => real/real => real

Where as using datatypes to represent the semantic type with limited possibilities for type conversion provides more automatic checking of type assignments and conversions. So that the result type of the type would be acceleration

(pcKesselRun/msFoo)/msBar => (parsec/millisecond)/millisecond => velocity/millisecond => acceleration

This means rather than relying on humans to see the wrongness is code, the compiler does it for us.

Too much hard work?

In small projects I would agree that this is in no way required. At that point the entire project fits in the programmers head and there is probably just one programmer working on it.

In languages with adequate type systems, the amount of code to define a new type is minimal (excuse my appalling Haskell)

newtype Velocity = Velocity Double deriving (Eq, Ord, Read, Show)

(/) :: Velocity -> Time -> Acceleration
(/) vel time = ....

At the point where a project starts to require interfaces to allow different people code to interact then it becomes worth the added complexity. It would allow different teams to use different systems of measurement. Using this sort of system could have avoided Mars Climate Orbiter crash. The crash was caused by one team using metric and the other imperial units of measurement.

Even if it wouldn’t have helped with the Mars Climate Orbiter it would have helped with SDP, where at one point half the system worked in radians and the other half in degrees. Ogre3D solves the problem by having two angle types and taking advantage of the implicit type conversion feature of C++.

But dynamic languages…

It doesn’t matter if the type system is dynamic or static, it would just tend to fail at a different point. Where as a static language would fail at compile time a dynamic language would fail at runtime. For the following hypothetical Python example, this would fail if the time object doesn’t have any function to_seconds defined when trying to execute the second line.

class Distance(object):
    def __init__(self, ...)
        ...

    def from_meters_per_second(self):
        return ...

    def __div__(self, time):
        return Velocity.from_meters_per_second(self.to_meters()/time.to_seconds())

With a dynamic language types are only checked at run times when the code is executed as opposed to static languages in which the types are checked at compile time. Having a dynamic system that raises an exception as opposed giving the wrong result better as it is far clearer to the developer that there is a problem and it highlights exactly where the error is. This happening in production isn’t ideal where the exception would lead to the loss of a 193 million space craft. The probability of errors could be reduced by using unit tests that exercise the used code paths.

Was Joel wrong?

In Joel’s defence in a language restricted in some way, such as not being able to define new date types, Applications Hungarian Notation may prove a improvement. In a language that supports it Applications Hungarian should be avoided. In using a type system to the fullest extent, it shouldn’t just make wrong code look wrong. It should make wrong code noticeably fail, either by not compiling or by raising an exception.

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