It's our time to shine!

It is week 10 already! Time flies so fast that the end of the semester is closing in. Although our software is still in progress, its shape has been formed after 8 weeks of tireless working and now it can function smoothly as expected. This exciting journey has been proven a great learning opportunity for me: we have overcome communication barriers, learnt how to collaborate with each other, and gained amazing experiences of developing software. We need not only to keep improving and finalising our product, but also to prepare for the forthcoming software demo, which is also the final oral presentation of CS2101. However, perfection is not easy to pursue as we still encounter many challenges in the preparation process.

Firstly, although we have indeed gained some experiences in preparing presentation, the last OP, software demo, is somehow a bit different as opposed to the previous two ones because of some factors beyond our control. One of the things which can go wrong is that our software might not perform correctly when we are presenting. There are potential bugs and glitches in our programmes that can crash the whole system and prevent it from operating normally. The controller class, which parses users’ inputs, is possibly the weakest component in our system since it is exposed to all variations of inputs. In order to reduce the chance of unexpected behaviours, we have composed several scripts containing commands that might be taken as inputs. Before presenting, we should test these scripts carefully on the software to ensure that they will function correctly. Thereafter, our presentations will follow accordingly to these scripts so that we can manage them better. These preparatory works are also precious experiences for us to deal with risk in the future.

Secondly, one influential criterion to evaluate the outcomes of a demo session is how well its presentations are delivered. Software demo is a valuable opportunity to introduce one’s product and demonstrate its features and user-friendliness to the target audiences. Therefore, enthusiasm plays a crucial role to make a software demo successful. Only when the developers themselves truly love their software, they are able to pass their passion to the audiences. In contrast, software will certainly fail to convince the prospective users if its own developers lack interest. The presenter’s level of enthusiasm and the methods to convey information will determine how the audiences would respond. A presentation is likely considered successful when attention and satisfaction from the audiences can be observed. Although a long applause at the end may not confirm too much, a presenter has to be engaging until his or her last words. 

In a nutshell, all preparatory work has brought great lessons to me. I am prepared to step into my future profession in which making live presentations and group collaboration are essential. I sincerely appreciate all experiences I have obtained from this module and all efforts we have put together into it. Let us wrap up our exciting journey by an excellent demo session. Eventually, not winning or losing but learning really matters.

My reflection on CS2103T project

In my opinion, it is impossible for a project not to possess any problems. For every team, regardless of the perfection of the team, there will definitely be challenges in order to deliver an extraordinary product. On the contrary, teams that find no problems with themselves are likely to have a big bang eventually. It is because when the problems are discovered, it is too late and likely to be unsalvageable. Therefore, the sooner the problem can be identified, the higher the chance to analyze and solve it. To emphasize, analyzing is definitely vital for figuring out the approach for the best solution.

In our project, To-Do Manager (TDM), one of the biggest and hardest problems we have encountered so far is implementing the multipurpose command bar (textual input) to facilitate the requirements. The problem started around week four when our team decided the architecture and the Application Program Interface (API) for our system. We have not realized the importance of having a well-implemented command bar. At the point of time, we just treated the command bar as a decorated feature for our fancy Graphical User Interface (GUI). Hence, we thought that implementation of the command bar was not a big deal despite that we were given target user Jim, an imaginary geek, who would rather type than use the mouse because of his fast typing speed.

The first part of the problem, which was facilitating requirements, kicked us in last week. After the fifth lecture of CT module, we realized that we had been really off tracked. Dr. Damith spent almost half an hour just to clarify and emphasize on the importance of a multipurpose command bar in the project. This devastating news implied that we have wasted two weeks in figuring out the software architecture that would need to be modified definitely. Moreover, as time went on, we noticed that the problem was not just that bad. The second part came right after discussions about refiguring out the project’s API. We eventually find out that the implementation of the desired multipurpose command bar, especially parsing–commands is extremely hard for us to solve ourselves.

The first cause of this problem is the lack of understanding on the requirements. We somehow shifted the main focus of the project from textual input to graphic interface during discussions. Another major cause is that many of us are perfectionists. We all aimed to build the best TDM with the most powerful multipurpose command bar ever. However, our ambitious goal is really a stumbling block in the implementation of our project.

The best solution for the problem at this point of time is try to find a suitable third–party library for the parsing–commands that can satisfy our requirements. Although using the external works is not encouraged, it is still a good opportunity for us to learn from how people handle the problem. Moreover, the library can be extended to be technically fit for our own project. Another possible solution is to scale down the goal and implement the slightly less ambitious multipurpose command bar, i.e. using flags to indicate transitions instead of users’ languages. Although the original goal has not been achieved completely, it is quite an acceptable solution to the hard problem that we have encountered.

Finally, it should be bear in mind that this is just the beginning stage; we still have a long way to go. Challenges are crucial for the success. I have a strong faint that we are capable of overcoming every single obstacle we face and our team can finally produce an outstanding product that can be applied in reality.

My reflection on my own team T2-G3. We can do that!

This is my first blog written using blogger.com and it is also the first blog in my communication module CS2101. The principles of communication and team behaviors actually includes lots of things, hence I will only discuss some principles related to my team discussion and its benefits.

I am really proud of my team because all of my team-mates have done a very good job so far. We have followed all the instructions in how to form a good team and what should be done in order to maintain the quality of the team we have built. Being the leader of this team in C1 is really my pleasure because all of the team-mates are really nice and sincere. That is the reason why I said in class that honest is the most important characteristic in order to make a good team, and my team-mates have also shown that in every team meetings by asking or answering question arisen from team discussions. 

Moreover, each member in the team has been punctual and responsible for the meetings. Being responsible is also very important in order to make a great team. One of my friends, Kok Hui, even went early most of the times and always text other team-mated that he has arrived. The others also came on time so that we can always start the meeting on time and work effectively to meet the requirements in the agenda. My team mates also prepared everything, or at least the main thing, before they come for the discussion. In addition, when one of us is speaking, others will listen and speak up only if it is necessary. I really appreciated what my team mates did in order to achieve the success of the first oral presentation - the OP1 - Intercultural Communication. We really did it, kudos for my team-mates!

Conflicts are unavoidable in group discussion, especially when the group encounter the sensitive problems such as choosing the leader or deciding who will present which part in the oral presentation. By using negotiation skills and human understandings we have learnt from the course, conflicts finally have been resolved in constructive ways. In my opinion, conflicts can be seen as a good chance for us to say what we think about and to hear what other members need. Moreover, a big lesson I have learned from conflicts was that in some cases, a member has to sacrifice for the sake of the team.

Break is also very important in every meeting in order to avoid fatigue and how to break at the right time is even more important. In my team, we always have a break in a meeting when everybody feels tired. By maintaining an open and friendly environment for discussion, we can select a good time for break quite easily. In my point of view, break is also a good chance for each of us to share about culture, study and even something really personal. Sharing is a powerful tool to deal with interpersonal communication we have ever encountered.

All in all, I really satisfy with the performances of my team so far. As we will work with each other in the rest of the semester, I really hope that we will have a wonderful time together and a successful semester ahead.