Assignment 1 experience

I did not write my blog last week. This week I will make up for it by summarizing my assignment 1 experience, which is really something I never experienced before.

First of all, I improved much in terms of php and sql skills. I wrote essentially all php functions for the group ( and seems that is the only programming thing I did ). Connecting to the database, uploading information, downloading information, dealing with tables. It is always true that only when I dirty my hands and stretch to the limit, could I make progress. I also experienced myself that writing programs for a team project is really really different from writing simple scripts. As I did not plan well on how I am going to write the programs and what are the functions needed, I encountered numerous problems. The biggest problem is that I did not structure my scripts well, I should have spent an hour or two thinking about how many files I need, how to name them, where to put them, how to name the functions in a good manner. The result is that I ended up with very messy scripts. Files are everywhere and the function names are all messed up. This really makes using and debugging (especially) of functions very difficult. Another issues is that as I did not have a full picture of how every single page should operate and even what pages are needed, I got screwed up with by arguments passed between pages. For example, I wrote the page to display data retrieved from the database, actually I need to display two different tables' contents so I trivially thought about writing two different files. When I finished one page I realized that the other page would be only different in a very small portion from the first page. So I decided to merge the two pages. As I did not plan to display both tables, I need to modify the page first and this takes quite a while. After that I found I had to post arguments from the calling page so that it could decide which table to display. So I went back and add in the arguments. Finally, I have to patch the page to receive the arguments. After the patch worked, I found that there could be another page calling the merged page also, so I went back again to add in more arguments to every page. When the page finally worked, I found it became completely unmaintainable, which is obviously very bad thing. The database tables is another example. We designed the tables and gave columns trivial names we thought of. Then it turned out that many of the functions with sql queries would be much easier if the column names were given in a logical manna. Last but not least, I had a much deeper understanding of functions. I should have written the functions in a manner that without knowing anything about how the function works, my teammate could still use it. Unfortunately I did not do that well. Sometimes my teammates had to refer to the function itself to study it before they could use it. My documentation was poor so it worsened the thing. Actually I know it will always take much effort before I can really write functions like that, so I am not discouraged about that :).

Second thing is about my experience on team project. Frankly speaking, CS3216 Assignment 1 is my first serious team project. I did not have experience in it and it seems nor did any of my teammates. We started out without an aim, without consideration of details, without time management, in essence, without a PLAN. So everything was of low quality and slow. Obviously it contributed to my bad experience of scripts management as described in the above paragraph. Thinking about it now, we should have discussed about the functionalities and general layout of the application and then settled down the rough paper version of the homepage. Then we would know where to go and would not have wasted so much time on figuring them out separately. I was also in lack of communication with my teammates, it often happened that I sat there, happily coded for 4 hours and feeling encouraged that my script worked when my teammate told me that the function was not what he wanted. Well, communication is vital, the same reason why a true quad-core processor is always faster than a "glued" quad-core processor with 2 separate dies linked by a bridge.

Last point, about the application itself. I personally believe that the concept of our app (enabling easy and fast secondhand deals in campus) is correct. As I myself is fond of second-hands and I know what I need is ease, speed and safety in transactions. Our app enabled this feature as within campus, all what I need are already guaranteed. Furthermore, within campus, there are always so many things to buy and sell. Laptops, shafts, bread bakers, fridges and so on. We added in many features to make it easier for people to use the app. For instance, we managed to track the users' last active time to enable them viewing what new items were posted by clicking a button on the homepage. The sad thing about our application is that firstly, its UI really needs improvements. Maybe we should not blame as none of us is a designer. Leaving it there, we have another serious problem-the documentations and descriptions for the application is so poor that the user do not really know what they are using and how to use it. This is really a failure and I swear it would not happen again in the final project.

One phrase in conclusion, if you fail to plan, you are planning to fail ( is there any copyright issue :P? )