This site is from a past semester! The current version is here.

Week 2 [Aug 19]

Admin Appendix B (Policies) → Policy on tech help

Policy on tech help

Do not expect your tutor to code or debug for you. We strongly discourage tutors from giving technical help directly to their own teams because we want to train you in troubleshooting tech problems yourselves. Allowing direct tech help from tutors transfers the troubleshooting responsibility to tutors.

It is ok to ask for help from classmates even for assignments, even from other teams, as long as you don't copy from others and submit as your own. It doesn't matter who is helping you as long as you are learning from it.

We encourage you to give tech help to each other, but do it in a way that the other person learns from it.

Admin Tools

Learning Management System: This module website is the main source of information for the module. In addition, we use LumiNUS for lecture webcasts and for admin matters (e.g., announcements, file submissions, grade book, ...).

Collaboration platform: You are required to use GitHub as the hosting and collaboration platform of your project (i.e., to hold the Code repository, Issue Tracker, etc.). See Appendix E for more info on how to setup and use GitHub for your project.

Create a GitHub account (if you don't have one yet), as explained in the panel below.

Relevant: [Admin Appendix E - GitHub: Creating an Account ]

See Appendix E - Using GitHub for more information.

Revision control: You are required to use Git. Other revision control software are not allowed.
The recommended GUI client for Git is SourceTree (which comes bundled with Git), but you may use any other, or none.

Install Git and a Git GUI client on your computer.
SourceTree comes with bundled with Git i.e., if you install SourceTree, you get both Git and a GUI client in one shot.

Set Git user.name: We use various tools to analyze your code. For us to be able to identify your commits, we encourage you to set your Git user.name in all computers you use to a sensible string that uniquely identify you. You can to GitHub username or as your Git username. If this user name is not set properly or if you use multiple user names for Git, our tools might miss some of your work and as a result you might not get credit for some of your work.

After installing Git in a computer, you can set the Git username as follows:

Open a command window that can run Git commands (e.g., Git bash window)
Run the command git config --global user.name YOUR_GITHUB_USERNAME (omit the --global flag to limit the setting to the current repo repo)
e.g., git config --global user.name JohnDoe or from within the repo git config user.name JohnDoe

More info about setting Git username is here.

Communication: Keeping a record of communications among your team can help you, and us, in many ways. We encourage you to do at least some of the project communication in written medium (e.g., GitHub Issue Tracker) to practice how to communicate technical things in written form.

We encourage you to post your questions/suggestions in this github/nusCS2113-AY1920S1/forum.
You can use our slack channel https://nus-cs2113-ay1920s1.slack.com for team communications. You need to join the slack channel (you'll need to use an email address ending in @nus.edu.sg, @comp.nus.edu.sg or @u.nus.edu) to start using this channel).
- Note that slack is useful for quick chats while issue tracker is useful for longer-running conversations.
- All official communications from the teaching team will happen via the github/nusCS2113-AY1920S1/forum; the same will be linked to in LumiNUS announcements.
You are encouraged to use channels with a wider audience (i.e., the GitHub issue tracker) for module-related communication as much as possible, rather than private channels such as private slack/FB messages or direct emails. Rationale: more classmates can benefit from the discussions.

IDE: You are recommended to use Intellij IDEA for module-related programming work. You may use the community edition (free) or the ultimate edition (free for students). While the use of Intellij is not compulsory, note that module materials are optimized for Intellij. Use other IDEs at your own risk.

If you have an older version of the IDE, we recommend updating to the latest version (i.e., 2019 edition).

Analyzing code authorship: We use a custom-built tool called RepoSense for extracting code written by each person.

We recommend you ensure your code is RepoSense-compatible by v1.3

We use a tool called RepoSense to capture your contributions (i.e., each student's code) for grading.

_{Figure: RepoSense Report Features}

1. View the current status of code authorship data:

The report generated by the tool is available at Project Code Dashboard. The feature that is most relevant to you is the Code Panel (shown on the right side of the screenshot above). It shows the code attributed to a given author. You are welcome to play around with the other features.
Click on your name to load the code attributed to you (based on Git blame/log data) onto the code panel on the right.
If the code shown roughly matches the code you wrote, all is fine and there is nothing for you to do.

2. If the code does not match:

Here are the possible reasons for the code shown not to match the code you wrote:
- the git username in some of your commits does not match your GitHub username (perhaps you missed our instructions to set your Git username to match GitHub username earlier in the project, or GitHub did not honor your Git username for some reason)
- the actual authorship does not match the authorship determined by git blame/log e.g., another student touched your code after you wrote it, and Git log attributed the code to that student instead

3. You can run RepoSense locally:

You can install reposense from the releases page, and generate the report locally to check.
Use the two methods described in the RepoSense User Guide section Configuring a Repo to Provide Additional Data to RepoSense to provide additional data to the authorship analysis to make it more accurate.
- If you add a config.json file to your repo (as specified by one of the two methods):
  - If your commits have multiple author names, specify all of them e.g., "authorNames": ["theMyth", "theLegend", "theGary"]
  - If updating the config file as described above results in an accurate report, pass the list of authorNames to the lecturer so that the centralized dashboard can be updated to reflect the contributions accurately.
- If you add @@author annotations, please follow the guidelines show below.

Adding `@@author` tags to indicate authorship

Mark your code with a //@@author {yourGithubUsername}. Note the double @.
The //@@author tag should indicates the beginning of the code you wrote. The code up to the next //@@author tag or the end of the file (whichever comes first) will be considered as was written by that author. Here is a sample code file:
```
//@@author johndoe
method 1 ...
method 2 ...
//@@author sarahkhoo
method 3 ...
//@@author johndoe
method 4 ...
```
If you don't know who wrote the code segment below yours, you may put an empty //@@author (i.e. no GitHub username) to indicate the end of the code segment you wrote. The author of code below yours can add the GitHub username to the empty tag later. Here is a sample code with an empty author tag:
```
method 0 ...
//@@author johndoe
method 1 ...
method 2 ...
//@@author
method 3 ...
method 4 ...
```
The author tag syntax varies based on file type e.g. for java, css, fxml. Use the corresponding comment syntax for non-Java files.
Here is an example code from an xml/fxml file.
```

<textbox>
  <label>...</label>
  <input>...</input>
</textbox>
...
```

Do not put the //@@author inside java header comments.
👎

/**
  * Returns true if ...
  * @@author johndoe
  */

👍

//@@author johndoe
/**
  * Returns true if ...
  */

What to and what not to annotate

Annotate both functional and test code There is no need to annotate documentation files.
Annotate only significant size code blocks that can be reviewed on its own e.g., a class, a sequence of methods, a method.
Claiming credit for code blocks smaller than a method is discouraged but allowed. If you do, do it sparingly and only claim meaningful blocks of code such as a block of statements, a loop, or an if-else statement.
- If an enhancement required you to do tiny changes in many places, there is no need to annotate all those tiny changes; you can describe those changes in the Project Portfolio page instead.
- If a code block was touched by more than one person, either let the person who wrote most of it (e.g. more than 80%) take credit for the entire block, or leave it as 'unclaimed' (i.e., no author tags).
- Related to the above point, if you claim a code block as your own, more than 80% of the code in that block should have been written by yourself. For example, no more than 20% of it can be code you reused from somewhere.
- 💡 GitHub has a blame feature and a history feature that can help you determine who wrote a piece of code.
Do not try to boost the quantity of your contribution using unethical means such as duplicating the same code in multiple places. In particular, do not copy-paste test cases to create redundant tests. Even repetitive code blocks within test methods should be extracted out as utility methods to reduce code duplication. Individual members are responsible for making sure code attributed to them are correct. If you notice a team member claiming credit for code that he/she did not write or use other questionable tactics, you can email us (after the final submission) to let us know.
If you wrote a significant amount of code that was not used in the final product,
- Create a folder called {project root}/unused
- Move unused files (or copies of files containing unused code) to that folder
- use //@@author {yourGithubUsername}-unused to mark unused code in those files (note the suffix unused) e.g.
```
//@@author johndoe-unused
method 1 ...
method 2 ...
```
Please put a comment in the code to explain why it was not used.
If you reused code from elsewhere, mark such code as //@@author {yourGithubUsername}-reused (note the suffix reused) e.g.
```
//@@author johndoe-reused
method 1 ...
method 2 ...
```
You can use empty @@author tags to mark code as not yours when RepoSense attribute the to you incorrectly.
- Code generated by the IDE/framework, should not be annotated as your own.
- Code you modified in minor ways e.g. adding a parameter. These should not be claimed as yours but you can mention these additional contributions in the Project Portfolio page if you want to claim credit for them.

Admin Project: Overview

The high-level learning outcome of the project (and to a large degree, the entire module):

Can contribute production quality SE work to a small/medium software project

Accordingly, the module project is structured to mimic a real-life software project in the inception stages. In this project you will,

conceptualize a given product,
implement enhancements to the product and,
have it ready to be continued by future developers.

Admin Project: The product

In this semester, we will implement and enhance a simple personal assistant, Duke. In the initial phase, you will design and develop Duke to manage tasks for a user. A sample interaction with Duke is as shown below.

    ____________________________________________________________
      ____        _        
     |  _ \ _   _| | _____ 
     | | | | | | | |/ / _ \
     | |_| | |_| |   <  __/
     |____/ \__,_|_|\_\___|

     Hello! I'm Duke
     What can I do for you?
    ____________________________________________________________

list
    ____________________________________________________________
     Here are the tasks in your list:
     1.[T][✓] read book
     2.[D][✗] return book (by: June 6th)
     3.[E][✗] project meeting (at: Aug 6th 2-4pm)
     4.[T][✓] join sports club
    ____________________________________________________________

todo borrow book
    ____________________________________________________________
     Got it. I've added this task: 
       [T][✗] borrow book
     Now you have 5 tasks in the list.
    ____________________________________________________________

bye
    ____________________________________________________________
     Bye. Hope to see you again soon!
    ____________________________________________________________

This product is meant for users who can type fast, and prefer typing over mouse/voice commands. Therefore, Command Line Interface (CLI) is the primary mode of interaction.

Relevant: [Admin Project Contstraints → More info about the 'CLI app' requirement ]

Admin Project: Scope

project expectations

Project phases

The project will run in two phases.

In Phase 1, you will be working individually to develop the foundation of your codebase
- This will give you an opportunity to familiarize with Java programming
In Phase 2, as a team, you will enhance the project, building on the codebase of Phase 1

The project consists of the following increments:

Levels: A series of features, meant to be added to Duke in the given order, although some can be skipped. These have been named Level 1 to Level 10 to indicate how the features make the product progressively "level up".
Extensions:
- Category A These are internal/feature enhancements meant to help you practice a specific Java or an SE technique.
- Category B These are enhancements related to task tracking.
- Category C These are enhancements, not specifically related to task tracking.
- Category D Each of these adds the ability to track another type of entities.

Phase 1

Phase 1 comprises Levels 1 to 10 with some Category A and Category B extensions.

Phase 2

In Phase 2, each of you will develop one enhancement each from Category C and Category D.
However, you need to ensure that the overall product is cohesive in nature, which means, as a team, you need to decide on a few things before embarking on developing the enhancements.
The following sections may help you decide on the enhancements.

Project Direction

In general, each team is expected to take one of these two directions:

[Direction 1] Optimize the task manager for a more specific target user group:

After Phase 1 of the project, think about optimizing your project to suite a specific target user group when you implement Category C and Category D enhancements.
A task manager:
- for users in a specific profession e.g. doctors, salesmen, teachers, etc.
- based on the nature and scale of application e.g. huge number of tasks (user group admins), highly volatile task list, for users who organize group events etc.
[Direction 2] Morph the task manager into a different product:

Given that Duke provides capabilities to manage certain types of elements (i.e., tasks), you can use it as a starting point to create an app that manages something else in Phase 2. Model the Category C and Category D enhancements to cater to the new app that you want to develop.
An app to manage:
- Bookmarks of websites
- Thing to memorize i.e. flash cards, trivia
- Forum posts, news feeds, Social media feeds
- Online projects or issue trackers that the user is interested in
- Emails, possibly from different accounts
- Multiple types of related things e.g. Contacts and Tasks (if Tasks are allocated to Contacts)
This is a high-risk high-reward option because morphing requires extra work but a morphed product may earn more marks than an optimized product of similar complexity.

Target user profile and value proposition

For either direction, you need to define a target user profile and a value proposition:

Target user profile: Define a very specific target user profile.
💡 We require you to narrow down the target user profile as opposed to trying to make it as general as possible. Here is an example direction of narrowing down target user: anybody → teachers → university teachers → tech savvy university teachers → CS2113/T instructors.

Be careful not to contradict given project constraints when defining the user profile e.g. the target user should still prefer typing over mouse actions.

It is expected that your product will be optimized for the chosen target users i.e., add features that are especially/only applicable for target users (to make the app especially attractive to them). w.r.t. the example above, there can be features that are applicable to CS2113/T instructors only, such as the ability to navigate to a student's project on GitHub
💡 Your project will be graded based on how well the features match the target user profile and how well the features fit-together.
- It is an opportunity to exercise your product design skills because optimizing the product to a very specific target user requires good product design skills.
- It minimizes the overlap between features of different teams which can cause plagiarism issues. Furthermore, higher the number of other teams having the same features, less impressive your work becomes especially if others have done a better job of implementing that feature.
Value proposition: Define a clear value proposition (what problem does the product solve? how does it make the the user's life easier?) that matches the target user profile.

Individual Expectations

[Individual] Expectations on Features

You are expected to add at least one feature each from Category C and Category D enhancements to the product.

At lest one feature should be end-user visible and end-user testable. Reason: If your feature cannot be identified and tested by the testers, we will not be able to give marks for the quality assurance of that feature.
The features should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add features that don't fit with the product.

We strongly recommend that you contribute to multiple (preferably, all) aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. If you limit yourself to certain aspects only, you will lose marks allocated for the aspects you did not do.

In particular, you are required to divide work based on features rather than components:

By the end of this project each team member is expected to have implemented at least one feature end-to-end, doing required changes in almost all components. Reason: to encourage you to learn all components of the software, instead of limiting yourself to just one/few components.
Nevertheless, you are still expected to divide the components of the product among team members so that each team member is in charge of one or more components. While others will be modifying those components as necessary for the features they are implementing, your role as the in charge of a component is to guide others modifying that component (reason: you are supposed to be the most knowledgeable about that component) and protect that component from degrading e.g., you can review others' changes to your component and suggest possible changes.

Here are some examples from the past project (Enhancing an AddressBook application) of different enhancements and the grade the student is likely to earn for the relevant parts of the project grade.

While these examples do not necessarily translate directly to the current project, they should give you an idea of the depth of the feature and the effort required to implement it (including automated tests and documentation).

Example 1 (Expected grade: A) : Add support for undo/redo
Example 2 (Expected grade: B) : Add support for viewing history

[Individual] Expectations on Lines of Code

Based on past experience, it is possible for a feature consisting of ~300-500 LoC of functional code and ~200-400 LoC of test code to earn full marks provided the feature does well in all grading criteria.
Note: The lines of code count mentioned above is counted after Phase 1 of the project

[Individual] Expectations on Documentation

You are expected to write user documentation and developer documentation for your features.
The objective is to showcase your ability to write the two types of documentation. If the documentation for your features is not enough to meet that objective, or does not reach the following minimal requirement, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
- Contribution to the user guide: 1 page
- Contribution to the developer guide: 3 pages
You are expected to showcase your ability to use the various UML diagrams (at least 2 types). As mentioned in the previous point, if the documentation of your features doesn't give you enough opportunities to do so e.g., your features only required minor updates to existing diagrams, you are expected to create those opportunities yourself by documenting proposed features or alternative designs. Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.

[Individual] Expectations on Testing

There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The less coverage you have, the higher the risk of regression bugs, which will cost marks if not fixed before the final submission.
You must write some tests so that we can evaluate your ability to write tests. (Please refer to Expectations on Lines of Code for LoC requirement).
How much of each type of testing should you do? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.

[Individual] Expectations on Teamwork

Team-tasks are the tasks that someone in the team has to do. Marks allocated to team-tasks will be divided among team members based on how much each member contributed to those tasks.
Here is a non-exhaustive list of team-tasks:
1. Necessary general code enhancements e.g.,
  1. Work related to renaming the product
  2. Work related to changing the product icon
  3. Morphing the product into a different product
2. Setting up the GitHub, Travis, AppVeyor, etc.
3. Maintaining the issue tracker
4. Release management
5. Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
6. Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)

[Individual] Roles and responsibilities

Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.
This is a non-exhaustive list; you may define additional roles.
- Team lead: Responsible for overall project coordination.
- Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
- Testing: Ensures the testing of the project is done properly and on time.
- Code quality: Looks after code quality, ensures adherence to coding standards, etc.
- Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
- Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
- Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
- [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
- In charge of[Component XYZ]: e.g. In charge of Model, UI, Storage, etc. If you are in charge of a component, you are expected to know that component well, and review changes done to that component in v1.3-v1.4.

Please make sure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it.

Team Expectations

Preserve product integrity: i.e. ensure,
1. features fit together to form a cohesive product,
2. documentation follows a consistent style and presents a cohesive picture to the reader, and
3. final project demo presents a cohesive picture to the audience.
Maintain product quality: i.e. prevent breaking other parts of the product as it evolves. Note that bugs local to a specific feature will be counted against the author of that feature. However, if a new enhancement breaks the entire product, the whole team will have to share the penalty.
Manage the project smoothly: i.e. ensure workflow, code maintenance, integration, releases, etc. are done smoothly.

Admin Project: Constraints

Your project should comply with the following constraints. Reason: to increase comparability among projects and to maximize applicability of module learning outcomes in the project.

Constraint-Typing-Preferred: The product should be targeting users who can type fast and prefer typing over other means of input.
Reason: to increase comparability of products, and to make feature evaluation easier for peer evaluators.
Constraint-Single-User: The product should be for a single user i.e. not a multi-user product.
Reason: multi-user systems are hard to test, which is unfair for peer testers as the number of bugs they find forms a component of the grade they obtain. Furthermore, the Constraint-Typing-Preferred is unlikely to fit a multi-user product
Constraint-Incremental: The product needs to be developed incrementally over the project duration. While it is fine to do less in some weeks and more in other weeks, a reasonably consistent delivery rate is expected. For example, it is not acceptable to do the entire project over the recess week and do almost nothing for the remainder of the semester. Reasons: 1. To simulate a real project where you have to work on a code base over a long period, possibly with breaks in the middle. 2. To learn how to deliver big features in small increments.
Constraint-Human-Editable-File: The data should be stored locally and should be in a human editable text file.
Reason: To allow advanced users to manipulate the data by editing the data file.
Constraint-No-DBMS: Do not use a DBMS to store data.
Reason: Using a DBMS to store data will reduce the room to apply OOP techniques to manage data. It is true that most real world systems use a DBMS, but given the small size of this project, we need to optimize it for CS2113/T module learning outcomes; covering DBMS-related topics will have to be left to database modules or level 3 project modules.
Constraint-OO: The software should follow the Object-oriented paradigm.
Reason: For you to practice using OOP in a non-trivial project.
Constraint-Platform-Independent: The software should work on the Windows, Linux, and OS-X platforms. Even if you are unable to manually test the app on all three platforms, consciously avoid using OS-dependent libraries and OS-specific features.
Reason: Peer testers should be able to use any of these platforms.
Constraint-Portable: The software should work without requiring an installer. Reason: We do not want to install all your projects on our testing machines when we test them for grading.
Constraint-No-Remote-Server: The software should not depend on your own remote server. Reason: Anyone should be able to use/test your app any time, even after the semester is over.
Constraint-External-Software: The use of third-party frameworks/libraries is allowed but only if they,
- are free, open-source, and have permissive license terms (E.g., trial version of libraries that require purchase after N days are not allowed).
- do not require any installation by the user of your software.
- do not violate other constraints.
and is subjected to prior approval by the teaching team.
Reason: We will not allow third-party software that can interfere with the learning objectives of the module.

Please post in the forum your request to use a third-party libraries before you start using the library. Once a specific library has been approved for one team, other teams may use it without requesting permission again.
Reason: The whole class should know which external software are used by others so that they can do the same if they wish to.

In addition, you are strongly encouraged to follow these recommendations as they can help increase your project score.

Recommendation-Security-Features: It is OK to use security features like login, provided you think through the solution completely e.g., having a login functionality to secure the application, but saving the password in clear text is no good, and can cost you marks in "Quality of feature(s)".
Recommendation-Minimal-Network: It is OK to use a reliable public API e.g., Google search but we recommend that you have a fallback mechanism (e.g., able to load data using a data file if the network is down). Reason: During the mass peer-testing session the network access can be intermittent due to high load. If your feature cannot be tested due to lack of Internet, that will have to be counted as a major bug, to be fair to those whose app is being tested and bugs found being penalized.
Recommendation-NUS-data: If you use NUS data (e.g., scrape data from an NUS website), please work with NUS IT directly to get their approval first. Even well-intentioned use of NUS data without approval can get you into serious trouble (has happened before). The teaching team will not be able to get approval for you as the use of NUS data is not a module requirement.
Recommendation-Testability: Avoid implementing hard-to-test (both for manual testing as well as automated testing) features or features that make your product hard-to-test. Reason: testability is a grading criterion. If you choose to implement such a feature, you will need to spend an extra effort to reach an acceptable level of testability. Here are some examples of features that are hard-to-test:
- Features that depend heavily on remote APIs: Those APIs can block your access if they mistake your automated tests as a bot attack. Some remote APIs require setting up accounts, keys, login etc, that will irritate the testers of your product and give a low rating to the testability of your work.
- Audio-related features: The peer testing of your product is done under exam conditions where it is not appropriate to play audio.

Recommendation-CLI-First: As per Constraint-Typing-Preferred, the input to the app needs to be primarily commands based (i.e., the app should be a CLI app). A GUI can be implemented and used to give visual feedback to the user rather than to collect input. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users, which will be graded under the product design criterion.
Some suggestions:
- Give keyboard alternatives to mouse/GUI inputs, if any.
- Regular typing is usually faster than using key combinations. Design the app in a way that you can do stuff faster by typing compared to mouse actions or key combinations.
- One-shot commands are faster over multi-step commands. If you provide a multi-step command to help new users, you also need to provide a one-shot equivalent for regular/expert users. Reason: We want the user to be able to accomplish tasks faster using CLI than a GUI; having to enter commands part-by-part will slow down the user.

If you are not sure if your product complies with a certain constraint/recommendation, please seek clarification by posting in the forum (preferred) or emailing the lecturer.

Admin A: Module Principles

These are some of the main principles underlying the module structure.

The product is you, NOT what you build.

The software product you build is a side effect only. You are the product of this module. This means,

We may not take the most efficient route to building the software product. We take the route that allows you to learn the most.
Building a software product that is unique, creative, and shiny is not our priority (although we try to do a bit of that too). Learning to take pride in, and discovering the joy of, high quality software engineering work is our priority.

Following from that, we evaluate you on not just how much you've done, but also, how well you've done those things. Here are some of the aspects in which we focus on:

We appreciate ...	But we value more ...
Ability to deal with low-level details	Ability to abstract over details, generalize, see the big picture
A drive to learn latest and greatest technologies	Ability to make the best of given tools
Ability to find problems that interest you and solve them	Ability to solve the given problem to the best of your ability
Ability to burn the midnight oil to meet a deadline	Ability to schedule work so that the need for 'last minute heroics' is minimal
Preference to do things you like or things you are good at	Ability to buckle down and deliver on important things that you don't necessarily like or aren't good at
Ability to deliver desired end results	Ability to deliver in a way that shows how well you delivered (i.e. visibility of your work)

We learn together, NOT compete against each other.

You are not in a competition. Our grading is not forced on a bell curve.

Learn from each other. That is why we open-source your submissions.

Teach each other, even those in other teams. Those who do it well can become tutors next time.

Continuously engage, NOT last minute heroics.

We want to train you to do software engineering in a steady and repeatable manner that does not require 'last minute heroics'.

In this module, last minute heroics will not earn you a good project grade, and last minute mugging will not earn you a good exam grade.

Where you reach at the end matters, NOT what you knew at the beginning.

When you start the module, some others in the class may appear to know a lot more than you. Don't let that worry you. The final grade depends on what you know at the end, not what you knew to begin with. All marks allocated to intermediate deliverables are within the reach of everyone in the class irrespective of their prior knowledge.

Admin Appendix C (FAQs) → Why you force me to visit a separate website instead of using LumiNUS?

Why you force me to visit a separate website instead of using LumiNUS?

We have a separate website because some of the module information does not fit into the structure imposed by LumiNUS.

On a related note, keep in mind that 'hunting and gathering' of relevant information is one of the skills you need to survive 'in the wild'. Do not always expect all relevant materials to appear 'magically' in some kind of 'work bin'.

Admin Appendix C (FAQs) → Why slides are not detailed?

Why slides are not detailed?

Slides are not meant to be documents to print and study for exams. Their purpose is to support the lecture delivery and keep you engaged during the lecture. That's why our slides are less detailed and more visual.

Admin Appendix C (FAQs) → Why so much self-study?

Why so much self-study?

Self-study is a critical survival skill in SE industry. Lectures will show you the way, but absorbing content is to be done at your own pace, by yourself. In this module, we still tell you what content to study and also pass most of the content to you. After you graduate, you have to decide what to study and find your own content too.