Blog #3 Reflection on Software Demonstration Preparation

  After we have finished our version 0.1 product, we are on the way to improving the product for version 0.2 and we are also required to give a software demonstration for the current product. During the preparation for the software demonstration, we have encountered a lot of problems here and there. Generally, there are two types of problems, one is team problem which is faced by the whole team; another is individual challenge which is encountered by individual when the team member is doing his or her own part of work. In my blog, I will discuss what difficulties I have conquered and what I have learned from them for both team problems and individual problem from my perspective.

1. Team Problems

1.1 Dividing the work:

  To divide the software demonstration work equally and systematically is very difficult. Through this hard process, I learn some experiences in dividing the team work. The experience is that before dividing the work, we need to take three points into consideration. All in all, we should follow the general flow of the operations in our software to give the audience a systematic image of our product. Besides, we also need to pay attention to the introduction, conclusion and the link between each other’s part, since we need consistency of our entire demonstration. Furthermore, we should consider the constraint that each member is more familiar with his or her own part of work in the version 0.1 product and the individual ability and skills. According to these factors, we finally successfully divide the demonstration work.

1.2 Merging the Demonstration Work

  After each team member finish his or her part of work, we begin to merge to present as a whole group. Then we encounter the problem of many overlaps in each other parts. For example, I mention some stuff which will also appear in other’ part since the stuff can be in both sides. We have to decide it clearly whether it is in my part or in other’s part. It is a very time consuming activity since it require many rehearsals to fix the problem. What I have learned is that we need a discussion of what we are going to present in each other part and come out an outline to prevent overlaps before everyone starts the work.

2. My problems

2.1. Not knowing the target audience

  I did not keep in mind who the audience was and what the audience was expecting for the demonstration (Exforsys Inc., 2009). In the conferencing for software demonstration, I misrecognised the audience as the developers. What was worse, I showed the half-done work without any necessary explanation and exposed the event identity number to the audience which is too technical. As a result, MS Lee got lost in the conferencing. Learning from these mistakes, I should confirm my target audience first and eliminate all technical details in my preparation for the software demonstration.  

2.2 Not making the transition

2.2.1 Transition for team

  I am the second presenter in the whole flow of the software Demonstration. What I learned is that I should take over the topic from the introduction part and have a reasonable transition to the detailed description of the features. Jumping from one topic to another topic with no apparent logic or purpose will distract the audience’s attention ("Transitions: Connecting the," 2003). To be honest, this is the first time for me to take such a role in the presentation. I think the challenge is how to make the transition smoothly and successfully. In addition, I also need to briefly mention the role for the following speakers about what particular part of the software they are going to demonstrate, so that the audience will have a general view of the demonstration flow.

2.2.2 Transition for my part

  There are two parts in each session of my demonstration, one is to introduce what features we plan to accomplish in the final version of the product; another is to demonstrate what features we currently have implemented. What I learned is that I should make enough and clear transitions between these two parts in each session. Otherwise, I would confuse the audience and make them disappointed to see the plain version compared to the one we proposed. To make it clearer, I should also give an outline about what are the completed features and what are the features we plan to do.  

2.3 Not having much interaction

Except the eye contract and gestures, I think I have made less interaction with the audience. I need to improve my speaking skills on making interaction with the audience. Otherwise, the audience will think that my presentation is boring (Stringfellow, 2011). However, this problem is very hard for me to solve. It takes time for me to have more proficiency in my English speaking. I will try my best to improve.  

In conclusion, I have learned a lot experiences in preparation of the demonstration for the software. Some of them are team work experiences; some are individual presentation skills. I will apply what I have learned in the further software demonstrations. I am looking forward to the final demonstration of our product.

References:

Exforsys Inc. (2009, 11 26). Know your audience. Retrieved from http://www.exforsys.com/career-center/presentation-skills/know-your-audience.html

 Transitions: Connecting the parts of your presentation . (2003). Retrieved from http://totalcommunicator.com/vol1_4/transitions_article.html

Stringfellow, A. (2011, 11 22). 5 ways to prevent boring webinars. Retrieved from http://blog.anymeeting.com/marketing-with-webinars/5-ways-to-prevent-boring-webinars/

Blog #2: The challenge of merging different-style codes

  Generally, our team has accomplished all the task successfully from the beginning of the semester till now. However, we do not get all the achievements smoothly but with overcoming many challenges here and there.Among these challenges, the different coding styles of each member left the deepest impression on me. The coding style should not be a problem when there is only one person writing the code. However, the problem comes when merging codes which are written by different people with different styles.

  Two weeks ago, I was assigned the work to merge my code with Sathish’s code together to submit for the CE2 (coding exercise two) for CS2103T. Initially, I thought it was a simple and easy task since we all had finished our part of codes and I did not need to do any additional work except putting them together. Unfortunately, it turned out that merging the code become a very heavy and time-consuming work for me. Sathish has the experiences to do software engineering before. Consequently, his code was well-commented and every variable had a proper name. However, due to the over-detailed information in his codes, I had to read every line like reading a story. It took me about an hour to understand all the methods and classes in his codes. When I began to put my code in, I found that I had no choice but to use his print method to display the results; otherwise I would have to write a new print method which would disobey the principle of software engineering. What was worse, I discovered that my code had already made out the best choices under the budget. Conversely, Sathish’s code made the selecting and separating solutions in the print method. I need to redo my selection so that I could make my code fit to his print method. Finally, the merging of code was finished. I had spent a whole afternoon doing the merging. Sadly, it turned out that it had not stopped yet. Sathish told me there was something wrong in printing the results. After communication with Sathish, I knew that I had misunderstood the meanings of his variables. Concurrently, Yukai pointed out a bug that the program could not take in the zero budget. After a hard time fixing these bugs, the work was eventually done.

  It is very common and natural that different people will have different style in coding. However, when it comes to merging the code written by different people, there will be confusions which will lead to lots of problems. I have come out three solutions. Firstly, coordination is needed in pre-coding period. For example, we should standardize all the names of the variables and distribute the work properly. Secondly, communication is necessary. If we come across any confusion of the other’s code, we should communicate with him or her directly and immediately. Thirdly, the tolerance and patience are needed. We should keep in mind that with the tolerance and patience, we can conquer any difficulty.

  The coding of the first version of this project will start in this recess week. Learning from the pain of merging code in CE2, we will do sufficient pre-coding coordination work to make the individual coding work more systematic. During the coding, we will conduct online meetings at least twice a week. Besides, we will also try our best to figure out the bugs and not give up. All in all, I have gained more confidence and look forward to accomplish the first version of this project successfully.

Blog #1： Communication and team behavior

  To apply what we have learnt in the classroom to become an effective listener and speaker as well as an eligible team player in the real communication is not as easy as I thought initially. However, through this meeting, I have made a lot of progress and have the confidence to go further.


  Last Friday, my group mates and I had the very first meeting. Before the meeting, I thought that I was the only PRC in this group whose English speaking skills was not that strong. I really feel the pressure and upset during the preparation. However, it turned out that the meeting with my group mates went on dramatically but successfully. At the beginning, I could not catch some of my team mates’ points and I asked them to restate with a shy face. However, the encouragement and sincerity from their eyes made me feel much better. On the other hand, my group mates were all glad to slow down the speaking pace and paraphrase their points in a more understandable way to me. After I got what they wanted to talk about, my pressure began to go away. Every group mates showed the willingness to communicate with each other on their faces as well as the body gestures. With the help of this atmosphere, every group mates were completely engaged in the discussion and the meeting went on smoothly.

  When the meeting nearly reached the end, we began to talk about the target users of the project. I had my opinion on the interface design for different users. However, I could not find some proper words to describe my idea. Therefore, I used a lot of gestures and paraphrased them in many different ways. But it did not work and made the situation even worse. My group mates got more confused. Because of the cultural differences, the way I organizing a sentence and choosing words is quite different from the native English speakers. Kim then said that she could understand Chinese and asked me to say it in Chinese. Then, I just used Chinese to directly express my idea. Unfortunately, this solution did not work either. The reason is that I already have tried hard in English and I could not translate them back into Chinese very quickly. The sentences were kind of mixture of the two languages. I had no choice but to switch back to English and try to paraphrase them again and again. Suddenly, Sathish got my points surprisingly. I felt so happy. What a long and tough process! I almost really lost my confident in speaking out my idea. From this process, I got to know that, if I could not express something in English, I should not change to another language; I should persevere to try my best to paraphrase and reconstruct the sentences till they are understandable.

  I think the barrier for me in speaking English is that I cannot combine the words which appear in my mind into proper sentences. Sometimes, after I spoke out a sentence, I knew that I have made a mistake and even myself could not understand the sentence. Due to lacking of enough practice of speaking English, I do not have the feeling of speaking the language freely and fluently. The group meeting really provides a platform for me to gain the practical English speaking skills. I think, as the time goes on, I will have more and more proficiency in my English speaking.             

the minutes taken in the group meeting 20/01/2012

The Important points from the meeting on 20/01/2012

1. Suggestion for storage: can store the data in the SQL/xml/text file

2. Two modes: User/Adam mode (need for clarification)

3. Feature 1: User needs enter the venue and duration (starting time and ending time)

4. Feature 2: Budget with quantities (check whether green or red---within or out of the budget)

5. Feature 3: Program

6. Feature 4: Delete events

7. Feature 5: The statistics information for the participants (provide summary analysis)

8. Feature 6: Advertising users through the emails 

Test post

Oh sorry, this is the test post...