The course will involve three large programming projects done in groups of two to three students. These project assignments will be announced at the start of the semester with definite submission deadlines. The set of assignments will be designed to develop skills and familarity with a majority of the following: make, configuration management tools, installation of software, archiving and creation of libraries, version control systems, documentation and literate programming systems, GUI creation, distributed state maintenance over a network, programming in different environments like desktop and handhelds, program parsing and compilation including usage of standard libraries like pthreads, numerical packages, XML and semi-structured data, simulation environments, testing and validation tools.
I suggest reading Part 1 (i.e. Chapter 1 and 2) of Beautiful Architecture first, then reading Head First Design Patterns over the course of the semester. The rest of Beautiful Architecture is a mixed bag, but all the remaining chapters are standalone articles so you can pick and choose any which catch your interest.
More details about each of these assignments will be provided as the semester proceeds.
The objective of these assignments is to give you experience with building large software systems as part of a team. Each assignment is a moderately large piece of software with several components, which will take careful planning, design, and implementation to carry out successfully. As such, you should start planning the system architecture and the work division between your group members early on, and not try to start and finish in a couple of days before the deadline.
You are also expected to use these assignments as an opportunity to learn and practice various tools and techniques for effective software development, as described below. You will be evaluated not just on the functionality of your program(s) but also on its design, modularity, maintanability, and your use of good development practices. Specifically, each of your assignments should follow these two guidelines:
Software architecture: Design your system first at a high level, as a collection of separate modules that are loosely coupled with each other. Document the purpose of each module, as well as the relationships between them i.e. how they depend on each other, how they use each other’s functionality, etc. Refer to Part 1 of Beautiful Architecture to get a better idea of what all this means and why it is important.
This architecture should be designed in advance by the whole group, after which implementation of each module should be done independently. Also document which students worked on which modules of the system. A brief report describing your architecture and work division must be part of your submission.
Coding style: Find a coding style guide that all of your team members can agree on (or at least tolerate), and try to stick to it. This will minimize inconsistency between code written by different people. To start with, you can consider one of Google’s many style guides, for example for C++, Java, and Python.
In addition, you should incorporate the following four requirements incrementally. The first assignment should include at least two (any two) of the four, the second should have at least three out of four, and the third should have all four.
Distributed version control: Create a private
Git repository for each assignment on https://git.iitd.ac.in/ and add me and the TAs
(. All code sharing should be carried out through this Git
repository, not by emailing code files back and forth between each
other. You will be asked to show the Git history during your demo. Note:
to prove that you have gone through this entire course webpage, send an
email to me with the word ‘esquivalience’ as the subject line before the
first lecture.narain, csz228228, mcs212155) as
viewers
Build automation / packaging: Use a build automation tool so that you do not have to recompile your entire project every time you change one file. Popular tools for this include CMake for C/C++ and Maven for Java. Use of a full-blown IDE like Visual Studio (not Visual Studio Code!) that manages your entire project including compilation counts as satisfying this requirement.
Unit testing: Define unit tests for each module of your codebase, so that they can be tested automatically and in isolation. Popular unit testing tools include GoogleTest (C++), JUnit (Java), and unittest (Python). It should be possible to meaningfully test each module of your program individually, ideally even if all other modules are broken or even deleted.
Autogenerated documentation: All meaningful components of the implementation (classes, methods, fields, functions, global variables, etc.) should have their purpose and usage documented in an informative way. The HTML documentation for the entire system should be generated from the code using a tool such as Doxygen (C++), Javadoc (Java), or Sphinx (Python).
There is one more requirement, not tied to any assignment:
Adapted from Dan Weld’s guidelines, via Mausam:
Collaboration is a very good thing. On the other hand, cheating is considered a very serious offense. Please don’t do it! Concern about cheating creates an unpleasant environment for everyone. If you cheat, you get a zero in the assignment, and additionally you risk losing your position as a student in the department and the institute. The department’s policy on cheating is to report any cases to the disciplinary committee. What follows afterwards is not fun.
So how do you draw the line between collaboration and cheating? Here’s a reasonable set of ground rules. Failure to understand and follow these rules will constitute cheating, and will be dealt with as per institute guidelines.
The Kyunki Saas Bhi Kabhi Bahu Thi Rule: This rule says that you are free to meet with fellow students(s) and discuss assignments with them. Writing on a board or shared piece of paper is acceptable during the meeting; however, you should not take any written (electronic or otherwise) record away from the meeting. This applies when the assignment is supposed to be an individual effort or whenever two teams discuss common problems they are each encountering (inter-group collaboration). After the meeting, engage in a half hour of mind-numbing activity (like watching an episode of Kyunki Saas Bhi Kabhi Bahu Thi), before starting to work on the assignment. This will assure that you are able to reconstruct what you learned from the meeting, by yourself, using your own brain.
The Right to Information Rule: To assure that all collaboration is on the level, you must always write the name(s) of your collaborators on your assignment. This also applies when two groups collaborate.