Evaluation plan: Task1 25%, Task2 30%, Task3 30%, Hackathon 15%

Background

We all use production quality software comprising millions of lines of code in our daily lives, be it the Android or IoS operating systems or the Facebook or Twitter social networking programs. However, most of us write tens to at max hundred lines of code, that sometimes fail to run on our own computers. This course is a self driven attempt to make our programming skills a bit less clumsy. Thinking carefully (a) how software should be organized into classes and functions to create better abstractions, (b) what data structures and parallelization can improve space-time efficiencies so that our code runs faster and uses less hardware resources like RAM, (c) how the different source and header files should be compiled and cleaned through Makefiles to remember dependencies, (d) how to use gdb instead of scattering printf-s all over the code to debug issues, (e) how to stop mailing our team-mates code versions and then not finding the code to upload in moodle 5 minutes before deadline by appropriate version control in git etc., are more important goals in this course, than just being functionally correct in the tasks.

What we will be doing

There will be three tasks and one end-sem hackathon. All three tasks should be done in groups of two. The hackathon will be an individual effort, mostly to see if everyone contributed equally through the semester and learned enough.

The first two tasks need to be implemented in C++ and the third in Java. The first task is mostly a warm up exercise to let you learn some new tools - Makefile, gdb, gnuplot, latex etc. It will be broken into four sub-tasks each a week long. The shorter evaluation cycles of a week will allow us to gauge your strengths and weaknesses better and see who among you might benefit from some discussions with me or the TAs. The second and third tasks will be given as a whole with over a month's time as deadline. (a) How to break these longer tasks into sub-tasks to make gradual progress, (b) how to keep working on it though the deadline is somewhat far to reduce last minute surprises, will need careful project planning and self discipline. The hackathon will be a one day event after the majors are done.

Tasks will be released on this webpage with submission links on moodle. Tasks need to be done on Linux machines. Though there is no lecture component in the course, the whole class will meet me and the TAs at some intermediate times. The time and venue will be communicated over email. The meetings (3-4 of them over the semester) will be about an hour long. We will discuss common issues we are finding in your submissions, the upcoming tasks etc. Students can ask any doubt that they might have in prior submissions or upcoming tasks.

Things to care about

Typically this is called the honour code for any course. Read as much as you want online resources and discuss among friends to understand the concepts. But the implementations, graphs and reports that you submit should be your own. No copy pasting of code from the internet or across groups. The reason is simple. We all will be professional programmers at some point in our lives with a Computer Science major or minor degree. Will we trust a civil engineer to build our bridges, if we know he copied all through his engineering projects? Will we trust a doctor to prescribe medicines, if we know that he passed exams by copying from cheatsheets? Will we trust a chemist to create those medicines if she copied all the chemical equations? The professional ethics that we expect from our politicians, doctors, civil engineers, chemists etc. should be the same as what we expect from ourselves. Cheating is insulting our own creativity and intellect.

[1] Task1: Create a small image processing library

[2] Task2: Write a simulator for an Indian road traffic intersection

[3] Task3: Design a two player game