Previous Lecture Lecture 23 Next Lecture

Lecture 23, Wed 05/19

Wed Lecture:

Tradeoffs: Quick Win, vs Maintainability

A case study:


Bottom line: for the short term

It’s a good idea though, when you do the “quick win” to have a concrete plan for refacoring.

As Bryan points out:

I think something we might want to make more clear to the students is that they will be expected to refactor/rewrite existing code in some cases, and that the code already present in the codebase isn’t necessarily the best example of good design

This is absolutely true, and it’s also going to be true of real world software development settings.

The default plan today, with one addition

Plan for lecture today: same as section yesterday, after a short discussion in the main room. Plus one twist : each team make a post on the project channel describing PRs done, and those in progress/planned.

The default plan

(1) Virtual standup: Each team member present posts in the slack channel for the chat an update with

(a) what stories they’ve worked since last time (b) status of each of those (c) any blockers (d) what they will work on next.

If you don’t know to work on next, say that for (d).

(2) Actual out-loud standup. Go over what you posted in the slack channel.

(3) Review kanban board, right to left. Try to get stuff merged and code reviewed (as a team) before taking on new stories.

But if you have done everything you can and are just waiting on staff, then start work on a new story. If you don’t have enough stories to work on, alert the staff.

TODAY ONLY: Please a post on your project channel #proj-ucsb-courses-search, #proj-ucsb-cs-las, #proj-mapache-search

(1) team number (2) theme (3) Summary the PRs that your team has merged into main (4) Summary of the work that your team is working on now.

WHY? This is not just “copy/paste” from your issues or PR descriptions, nor is it just busy work.

Purpose: inform other teams of info they may need to know in order to do their work.

Think about what level of detail would other teams really need… not too much detail, but just enough so that other teams have a notion of whether or not their work and your work are complementary, on a collision course, etc.

(4) Work on your stories, either together, or in separate breakout rooms.


Note that ^^^^ THIS ^^^^ is the default plan for every class from now to the end of the quarter, unless we instruct you otherwise. We may occasionally deviate from this, and there may be announcements, but this is the typical way that class goes. (This is also the typical way that devs work in real world sw dev teams…. except that instead of alerting the “staff” for new stories, it would be a shared team responsibility to work with the “product manager” and “ux designers” to come up with the new stories.)