This blog is about a question in our class today: should software copyright be patented? At first I thought that no, it shouldn't. Who on earth would ever patent ideas that are easily overlapped? But reviewing some cases happening recently in the Software and Game Industry, I have to rethink about my point of view.

The software industry is very very large. Starting with some simple ideas, the outcome software product can be very different. Let's take an example of the project I did last semester. In CS2103T, all of us (64 groups) have to write a program to simulate a to-do manager, a program that helps the users to manage tasks that they have to do everyday to make sure they can work effectively without worrying about forgetting everyday's task. The original idea was simple, but I was surprised that the products at the end of the semester are very different. All of them have unique GUI (graphics user interface) and perhaps, different data structure too. So it's very hard for one to determine whether a software is successful or not. We can only say if a program is successful financially or not. A well-known program can even perform worse than some less known program, but when referring to a program

The problems get more complicated when we come to game industry. In a game, it's not just simply the graphics that attract the users. What lies inside a successful game is a good story line, a unique art-style and a deep gameplay. Blizzard is a game producer that understand theses factors the most. 10 years ago, they released Warcraft 3, which is the base for World of Warcraft, the most successful MMORPG of all times. Warcraft 3 has a special feature: it provides users a World Editor, which allows the users to create map using their own creativity. They then can share it for other players to play together. One of the most successful map is Defense of the Ancient - DotA, which created another game genre: MOBA - Muli-Online Battle Arena. The problem is that Valve, another game producer, famous for some revolutionary game that changed the Game Industry like Half-Life, Portal,.. have seen the potential of this genre and they registered trademark for DotA 2 and even DotA 3. What matter here is that when playing the game, players can very easily notice that the heroes models designed in Valve' DotA 2 looks very similar to DotA, in which the map creator used Blizzard's original game models. The way heroes react to each other, aka 'skills' are also the same (actually the map creator transferred all skills from DotA 1 to DotA 2 so that players will not waste time exploring new gameplays and the developers are easier to work), which already means that these people are using Blizzard's ideas to make their own game without any contribution to Blizzard's game.

Challenges to our demo

We are approaching the end of the semester and also, the end of our product developing process and it's time to show our product to the public. Although getting the demo to work properly to show case our product is not something that is challenging for us, especially after all we have done, we still have to consider carefully about this. The following is the issue that I found we faced while preparing for this demos.

The first conflict we had is about whether we should use video to demonstrate our product or not. I myself always think that a good combination of these two methods is the best way to demonstrate a software project: the videos to show something cool that visually impress the audience and the live presentation to communicate with them closely to help them get used to the product. However, due to the scope of our project, which is only V0.2 of a commercial program to public to users, I think the live demo is the best for us. Through the live demo, we can keep contact with the audience. Demonstrating our product lively can also show the audience how easy and user-friendly our program is, to ensure with them that they will not have to deal with lousy troubles, like how to add such tasks, how to delete, etc. Of course, the live demo has some risks, we may encounter some unexpected problems such as laptop or projector stop working unexpectedly, but for me, this is the most flexible and most suitable for our product demo.

Once again, I want to emphasize that this demo is the first introduction to impress the audience, so we need to consider it carefully and make it the best the can do. Making this to be true is not challenging for us after the great jobs we have done. All we need to do is a bit more effort to make the presentation runs well. This is not hard at all and we can do it successfully.

Challenges encountered in the run up to the software demo

Powdering and polishing the software while preparing for the software demo is the penultimate lap in this ‘race’ to the end of this semester, with the actual delivery of the demo being the final one. It is true that we are facing the heat but this is where our personal and team skills come into play.

Our product is evolving by the day as a result of continual modifications in structure and functionality that we are incorporating to the beta version (V0.1). This became a point of concern when we wanted to finalize the version that we were going to use for the demo. A lot depended on this decision as speakers needed to equip themselves to handle operations concerning the functionality that they are focusing on. This problem was eventually solved as we decided that we will use that version last updated three days before the demo.

There was also this debate on the usage of a video during our demo. I personally felt that using a video was not a good idea as it lacked the throw and feel of a live presentation. Eventually we decided against using a video, thanks to the open-minded approach of my teammates. Our commitments, both academic and non-academic, continue to limit the time we spend on our preparations for the demo. This is something we must live with but perhaps more efficient time management can make life a lot easier.

Once again division of responsibility proved to be a big headache. The evident solution was that each of us present the part that we had developed as we would be most comfortable with that. All of us agreed to this albeit some minor changes. Coming up with a relevant story board, with equal emphasis on the different sections, for the presentation was also challenging. We were and still are discussing means by which we could add that additional bit of excitement and buzz to the demo. We have zeroed in on a few ideas but I do not want to spoil the surprise here!

From a technical point of view, the biggest problem that we are combating currently is the number of bugs in our program. The number of different scenarios that needs to be considered, while allowing users to type in commands, is quite large and this makes bugs inevitable. By bugs I refer to semantic and logical errors rather than syntactical errors. This is something which can be solved by testing the product extensively. At this point I would definitely like to acknowledge the contribution of my teammates in this testing process. A single person can never do justice to testing as his view is bound to be biased in some way. All of us have done extensive testing individually to ensure that the product is bug-free.

The spirit with which we are currently functioning is enough evidence that we are up to the challenge. If we continue to work like this and perhaps add that additional push, I am quite confident that we can pull this off successfully.

Lakshminarasimhan

Challenges of Our Demo

During the preparation of software demonstration, we did not have many challenges. I believe everything works well except for some small conflicts. I just describe the problems exist at least in my mind. Some have been solved and some we still need to work on. However, I do believe our presentation will be great!

We had some conflicts when we talk about we demonstrate by video or live demo. At first, I preferred demonstrate by video because I felt that was the method most of software companies used when publishing their new products. It is quite cool to use a fantastic video to show our product. Additionally, I thought video would help us to minimize the number of unexpected problems during the demo. We all know the computer is stupid and unreliable.  Moreover, I did believe we could focus more on talking and communicating with the audience if we make the demonstration as a peace of video since we do not need to type on keyboards while talking. I thought this will help us to make a better communication during the presentation.

However, Lakshmi and Shawn persuaded me. To demonstrating lively will attract more attention since audience are more likely to try our products lively in the demonstration instead of watching the video. We can even invite some of the audience to try our products. Moreover, Shawn did remind me that we do not need to type while talking since people will talk after they type the commands normally. Finally, I did realize that it is much more difficult to demo with video since we need to talk synchronically with the video. It is not an easy job and we need to rehearse many times. Moreover, if we use video, we have to follow the script strictly since we cannot change the video when we present. This may make the presentation boring. In contrast, it is much freer to do live demonstration. We can make change according to the situation.

Another small problem is that we haven’t finished our products for the demonstration. Until now, our search function, which is quite important, is not ready. Although I do believe, this will be finished before the demonstration, as I mentioned in the previous blogs, we need some buffer. Thus I think it is not good to do the job in last minute, some unexpected problems may happen. This is quite a small problem and I believe we will finish our product successfully. We did not have any buffer we came to the deadline of V0.1 a few weeks ago, but we still made it. Therefore, I still strongly believe we will make it!

Regardless of these small problems, I still believe our preparation of demonstration is good and we will make a good presentation. 

Problems, challenges and solutions in the preparation of our software demo

It is interesting to see how a group of guys came together not by choice but through random selection and somehow approach one of the final few milestones without much hiccups. And this milestone is preparation for the software demo.

The team faced a few problems during this preparation and I would like to highlight the two major problems we faced. The first major problem was each of us have a different perspective of how the software demo should be conducted and could not come to an agreement with one another. And the second problem was the dedication of roles for the software demo.

Different Perspectives

This was probably the biggest problem the group faced during the preparation. The crux of the problem was getting everyone to agree with an idea, and be comfortable with it. 

Even though we came from different culture, tradition and social upbringings, I do believe this problem would still persist even if all of us were to come from the same parents. This is so because each one of us thinks differently and each one of us has our own opinion.

There are no fix solutions to overcome this problem, but there was one very 'logical' solution which the team applied. That solution was having each one of us to compromise, not to stay hell bent on our own ideas and putting ourselves in each other's shoes. And through this the team adopts the best idea and integrate it into our demo. Each one of us listens to each other's ideas and opinions as a result each one of us developed a greater understanding with one another.

Dedication of roles

The other major problem we faced was actually deciding who is going to do what during the software demo. One of the main causes to the problem was actually being in such a diverse team, each one of us have different strengths in the area of presentation. Therefore the selection process became a headache, to choose who is going to do the main aspects of the demo and who is going to close and facilitate the QnA session. One solution the team came up with was taking into consideration the strengths and weakness of each individual in the aspect of presentation skills. And after taking this into consideration, the team then decided who is going to do which portion of the software demo. With this every member's contribution was justified.

The only reason why this solution worked was because everyone in the team was being honest with themselves regarding their capabilities in the area of presentation . As we recognize our own strengths and weakness, we did not feel that injustice was served as to why we are not given a particular role. Our team recognizes that each one of us have different roles to play to benefit the team, after all this is a team project.

Challenges
Conducting a live software demo for the first time was a challenge to the team. As none of us have any experience in doing a live software demo in front of an audience before, this becomes a daunting challenge. How are we suppose to react? How are we going present? How to interact with the audience? How to handle technical issues when problems occur? Are just some of the few questions that were brought up during our team discussions. Our team look in awe at how some software demos are being conducted by professionals, one example was a software demo conducted by the late Steve Jobs. One solution the team used to overcome this challenge was to look at how professionals conduct a software demo. As we learn from those people, we started to be familiar with the presentation style that was required and felt comfortable and confident with this genre of presentation.

One other possible solution the team took on to help us overcome our challenge was to constantly prepare and practice as a team for the demo. On top of this, the team had a qualified evaluator Ms Janet to come and evaluate at one of our demo rehearsals. By doing this, Ms Janet will be able to point out the strong points of our software demo so that we can work on them and make it even stronger. Besides pointing out the good points, she will be highlighting the bad points of the software demo as well so that we can improve on it. We recognized the benefits of having a qualified evaluator such as Ms Janet to come and evaluate our software demo.

Conclusion
Overall the team has come a long way now, as we head to the final third of the project, all these challenges faced by the us would only strengthen us for our future endeavours. Learning how to overcome such problems now and how to avoid the same problems in the future are valuable lessons each of us took home.

Shawn Teo Chee Yong

On our team's problems

We, being a multi-culture group, have been going through half of the semester. At the moment, I'm glad that we have done our job well. I have good experience working with you. And more time spending with you, I have more chance to realize some problems which we can improve. I want to have a clear sight into it.

First of all, we are lucky to be in a group where every member is strong in IT. However, that also means that we have to consider clearly to choose the best idea when discussing something. Let's take the GUI meeting for an example. When discussing about the features and how the GUI should look like, we have a lot of different ideas, all are interesting. I understand that you have good knowledge in IT and always have some solution to a problem, but if we can listen to each other and understand him a bit better, then perhaps we could have come up with more interesting ideas in our project.

This is a common problem faced by all teams, when all member are good at something in common, and it can be definitely resolved. We should listen to each other's ideas carefully and understand its pros, cons before we make any comments on that. We are all doing heavy work in this semester: Zhou Jun taking 8 modules, the other 3 taking CS2010, which requires a lot of coding efforts, so we don't have much time for meeting. Perhaps at this moment, each of us have personal stuff to do. Like me, I'm working on a NUSSU project and working part-time. But in the next weeks, when we have come to the coding stage, I think we have to meet more regularly and by then, we should have more time to discuss problems more carefully.

It is not something very serious and I think we can resolve it. It is a common problem that must be solved in order to improve teamwork ability. We're a great group, doing a great job and I believe we can pass all problems and go further in this project if we put more effort.

Insights into one of our problems

As I had pointed out earlier (in my previous blog post), being a team of like-minded people helped us gel as an outfit in the early half of the semester. We were to find out later that this by itself was one of our biggest shortcomings.

Let me expand on this problem. All of us are alike on many different fronts. Both while separating topics for our oral presentations as well as dividing responsibilities for our project, we found out that all of us were intent on taking up similar tasks/responsibilities. This was because our skill sets overlapped significantly. All of us are good programmers, natural leaders, speakers more comfortable while presenting topics with heavy content rather than abstract ones and so on. This is a problem as it restricts our variety to a great extent. An even bigger problem arises when we are left with no choice but to pick tasks outside of our comfort zone. This is bound to happen as we need to do a variety of subtasks for each submission with limited resources at hand.

We could solve this problem by proposing a system wherein a person can ask for what he/she wants and will be assigned the task on a first cum first serve basis. Still, this solution does not work fairly as team members who are extroverts tend to gain an advantage over others as they are the ones who generally speak out first. A possible advantage of this system is that it gives the silent members of the team an incentive to speak out thereby indirectly enhancing their communication skills. The least we could do is to ensure that the same guy does not suffer every time.

Every coin has two sides. Even this problem has helped us in certain ways. We were forced to move out of our comfort zones on a few occasions and hence were exposed to newer things. In this process, we had an opportunity to explore newer arenas which may be to our liking. I am quite sure that we wouldn’t have taken the pains to experiment otherwise and thus wouldn’t have realized our full potential.

Personally, I feel that I have gained a lot in this process. Opening presentations was not my forte. I now feel more confident when I am opening presentations. If I had been given the choice, I wouldn’t have opened presentations and thus would not have realized that I actually like it.

This problem – a result of our team composition – cannot be avoided but can definitely be resolved. It is our responsibility as a team to ensure that no team member suffers extensively because of a conflict of interest. I can tell that we are proceeding in the right direction from the way we have split tasks for our upcoming submissions. Hope that this good work continues!