March 2012 Archives

Something about the software

| No Comments

Hengyi Huang 3941474
Something about the first programming project.
We started the project fairly late. Actually we began thinking about how to design the scanner before weekend and literally started coding on Monday. We put tons of efforts on the next four days and we had a really hard time struggling through. Hours are wasted on debugging and we figured that there were barely enough office hours. Then we realised that we started the project too late...

However, we finished the project at the end. Generally we went through stages including designing, implementing testing and debugging. As for the designing stage, my partner and I went through the structures of scanner function and we discussed the potential components of the scanner. Then we went out to work on the individual components. Honestly I did not believe in the power of "writing test cases at the beginning". When we finished definitions of sub functions and went back to write the scanner function and then had it compiled, none of our functions worked! The next 12 hours were about figuring out bugs in different functions. It was really tough to figure out where specifically the bug was if you have not tested it thoroughly beforehand. For example, I thought there should be no problem with my definition of linked list because I have done similar things before. However, again, to my surprise, I spent over 4 hours thinking about why it was not working. Nothing should be taken for granted when it came to software programming. That was my feeling when I saw tons of "Error" messages yelling at me.

The second thing I did not do well is time managing. Now I realise why it is strongly suggested that we should start early and trying put certain amount of work on the project every day. It seems that its way more efficient if you spend two hours coding and then spend half an hour talking to your partner or TAs, compared to coding up to 4 o'clock two days before it was due. Communication is also a big issue. Every programmer should his/her partner updated about what is going on. I asked my partner to test function I wrote. It did not work that well. Whenever someone just starts working on a problem, he or she should own it from the beginning to the end.

The last thing is about specifications. We had trouble getting through that as well. Despite the fact the specifications for labs in this course are sometimes ambiguous, we should make sure we are clear on specifications before we move on.

Generally, I think this project is fun and we should do a better job next time.

About this Archive

This page is an archive of entries from March 2012 listed from newest to oldest.

Find recent content on the main index or look in the archives to find all content.