Week 10 [Mon, Oct 21st] - Project

tP: v1.4

  1. Do a postmortem of the previous iteration before the tutorial
  2. Plan the alpha version (v1.4)
  3. Deliver the alpha version (v1.4) Thu, Oct 24th 23:59
  4. Smoke-test CATcher [COMPULSORY] Fri, Oct 25th 16:00
  5. Start updating UML diagrams in the DG

tP: Alpha version → v1.4

Intro to tP Week 10

What's happening this week:

v1.4

  • Learning outcome: Able to tweak the product/project plan to match the available time/resources.
  • Product goal: Implement versions of all the features intended for final release.
  • Strategy: Add features based on priority, while maintaining a working product. It is OK if the features are rough around the edges, as they can be tweaked in the next iteration.

In this iteration, we learn from past iterations, and aim to better plan and better deliver another functional increment that would get you very very close to the final version in terms of raw functionality.
We call this the alpha version because this version is meant to be good enough for of the product.

First, in task 1 we look back at the previous iteration, to see what we can learn from it.
Then, in 2 we plan features to be implemented in this version, while aiming to come very close to the final product's feature set.
Finally, in 3 we implement those features to deliver the v1.4.

Things to note:

FAQ How much code/features is enough to get full marks?

Heads up: this is a BIG week of the tP!

Ideally, the tP work should be distributed equally across all tP works. In practice though, this can be uneven based on your other commitments e.g., most did less work in week 7-8 due to midterm exams.

If you were to pick one tP week to push the hardest, this week should be it! That is because in this iteration you need to implement all features that you plan to include in the final version (but they need not be fully polished).

1 Do a postmortem of the previous iteration before the tutorial

  • Discuss with the team how the iteration went (i.e., what worked well, what didn't), and your plans to improve the process (not the product) in the next iteration.
  • Submission: Keep notes about the discussion in your shared project notes document so that the tutor can check them later.

Like to try a new Git workflow? If you feel you are now comfortable with the forking workflow, and now you would like to practice another one, your team can choose to follow the feature branch workflow from now on.

2 Plan the alpha version (v1.4)

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

--Tom Cargill, Bell Labs

  • Decide the scope: Start by deciding what features you would include in the final product if you had only one more week to deliver them. In this iteration, aim to deliver at least a version of those features.
    🤔 What's the hurry to add all features right now? We will be enforcing a strict feature freeze at the end of v1.5 (more details in the panel below). Given you also need time to polish the features before the feature freeze starts (during which feature tweaks are not allowed), it makes sense to finish the bulk of the feature implementation in this iteration (v1.4), so that you have time to test and polish it in v1.5.

  • Plan the iteration: Decide the order/timeline for those features, record that plan using issues, and assign team members to those issues. Plan tasks based on priority, while staying breadth-first.

3 Deliver the alpha version (v1.4) Thu, Oct 24th 23:59

  • Follow the iteration plan you devised above, to deliver the features.
    Resist the temptation to try to deliver each of those features/enhancements in one PR. It is better to deliver a minimal version first, and improve it through subsequent PRs.
  • Manage the iteration better than then previous iteration (hopefully), as per what you learned/decided during the v1.3 postmortem.
  • Release v1.4. Include a jar file and detailed release notes (as before, the release notes should describe what's-new-since-the-last-release-note).
Ways to level up your tP game:
  1. Use parallel PRs: We encourage you to try sending parallel PRs (i.e., send another PR while the previous PR you sent is waiting to be merged) if you haven't done that yet. Reason: It's important to learn how to do that, because in most real projects it is common to have multiple open PRs from the same author.
  2. Maintain the defensiveness of the code: Use assertions, exceptions, and logging in your code, as well as other defensive programming measures (refer this week's topic on defensive programming for more details) when appropriate. This will be considered when grading your tP code quality.
    Remember to enable assertions in your IDEA run configurations and in the gradle file.

FAQ Is it enough to update existing UML content/diagrams or must we add new content/diagrams?

FAQ What if the features I added don't affect UML diagrams?

Some other relevant FAQs, repeated from last week:

FAQ Should we try to automate GUI testing as well?

FAQ All tests pass locally, but the same code fails CI in the PR. How come?

FAQ PR passed CI before merging, but fails CI after merging. How come?

FAQ PR CI fails because Codecov reports a drop in code coverage. What to do?

FAQ Are we allowed to deviate from the MVP Feature Specification submitted earlier?

4 Smoke-test CATcher [COMPULSORY] Fri, Oct 25th 16:00

  • This activity is compulsory and counts for 3 participation points. Please do it before the weekly deadline.

Some background: As you know, our includes peer-testing tP products under exam conditions. In the past, we used GitHub as the platform for that -- which was not optimal (e.g., it was hard to ensure the compulsory labels have been applied). As a remedy, some ex-students have been developing an app called that we'll be using for the PE this semester. We still use GitHub to record bugs reported in the PE but CATcher acts as a layer between you and GitHub, to ensure the bugs you report meet PE requirements.

This week, we would like you to smoke-test the CATcher app to ensure it can work with your OS, Browser, GitHub account, by following the steps given in the panel below.

  • [Heads up] Load-testing CATcher will be done during the upcoming weekly briefing (Fri, Oct 25th ), during the first 15 minutes of briefing. This is different from smoke-testing you did above, and this will count for participation separately.
    Therefore, remember to attend the briefing (via Zoom or F2F) at least for the first 15 minutes (this activity cannot be done any other time).

5 Start updating UML diagrams in the DG

This is a good time to get familiar with the diagramming tools used by the tP.

  • Each member is recommended to update at least one UML diagram in the DG, to match the changes you've done so far in v1.4. You may do this towards the end of v1.4, or soon after you finish it.
  • Deadline: This is not part of v1.4. So, you can do this even after you are done with the v1.4 release that is due Thursday 23:59.
    As this is a regular weekly task, the usual deadline applies i.e., Friday 1600, and as usual, if you miss the deadline, catching up within a few days will still turn it green.
  • Updating the DG text to match the diagrams is optional (it can be done later).
  • FYI, the panel below has some DG tips, some of which are related to drawing diagrams.

FAQ Why not wait till the end to add/update the DG diagrams?

End of tP Week 10

Have any suggestions to improve AB3?

Now that you have worked with AB3 codebase for a while, if you have any suggestions on how to improve AB3 (for future batches), feel free to post/discuss them in the forum.
Examples: places where the design/code can be simplified, hard to understand parts of the code, tips you can share with future batches, ...