Fall '21 Lecture Notes - Mon Aug 30 - Project Management

• video on YouTube
• transcript of video

Announcements

• New grading policy for assignment work
• A1: web site (☕☕) due in 1 week (Sep. 6 @ 8am)
  • this will serve info about your project, including deliverables
• A2: project management approach (☕) due in 1 week (Sep. 6 @ 8am)
  • we’ll talk about this today
• A3: user stories (☕☕) due in 2 weeks (Sep. 13 @ 8am)
• Plan to meet with your mentor this week (or get a 0 for this week’s mentor attendance)
• Feel free to discuss assignments with mentors (before and after)

Agenda

1. announcements
2. the goal of project management
3. communication overhead
4. tips and tools
5. bonus: hyperfocus
6. gathering user stories
7. the plan for Wednesday

the goal of project management

• goal: to keep the project moving
• (Hence the music before class: Float On by Modest Mouse)
• what’s hard about that?
• for a single person, only complexity is navigating dependency relationships
• for multiple people, you have to coordinate: who works on what?
• example: for a single-threaded program, you don’t need inter-thread communication

communication overhead

The Mythical Man-Month

• The Mythical Man-Month by Frederick P. Brooks, Jr. (heard of him?)
• projects used to be rated by person-months, e.g. “a 12 person-month project”
• this makes sense from a management perspective to predict cost and timeframe
• question: is a 1 person x 12 month project equivalent to a 12 person x 1 month project?
• almost as ridiculous as tasking 9 women to have a baby in 1 month
• key insight: rating project effort by person month assumes no communication overhead

quantifying overhead

• if there are 3 people in a room, how many handshakes are possible?
• answer: 3
• how about for 4 people?
• answer: 6
• adding 1 person doubled the number of handshakes!
• similar idea: how many communications must take place to coordinate n developers?
• formula: n * (n - 1) / 2
• the overhead scales exponentially! (O(n²))
• “Brooks’s Law”: adding developers to a late project only makes it later
• why? because the new developer has to catch up, adding communication cost to the project

reducing overhead

• recall primary goal of project management: keep the project moving
• secondary goal: to add as little overhead as possible
• in my experience in industry, most companies are moving to teams of 3–6 developers
• how to scale up? not with a broadcast (all-to-all) paradigm
• how do we scale up with data? fascinatingly similar question
• a good solution: trees, which tend to have O(lg(n)) operations
• this is why hierarchy is useful
• (there are also risks and dangers with hierarchy, of course…)

tips and tools

exploit natural seams in the work

• simple example: if there are 3 pages to create for the web site assignment, assign each person a page
• but there is often pre-work, before the parallelizable work (e.g. to read requirements and determine that 3 pages are needed)
• and there might be post-work, to synthesize everything into a coherent whole afterwards (e.g. share the site with people)
• the pre-work of task definition is typically considered project management overhead and not tracked explicitly as a task
• but post-work and other kinds of pre-work could be tracked as an explicit task
• related CS topic: the map/reduce paradigm in distributed algorithms
• remember Koalas to the Max: the seams might not be evident until you’ve gone some distance down the path

write things down

• why? our human memory is fallible
• we tend to remember things in our own favor :-)
• but having things written keeps us honest and avoids needless conflict
• comment threads in Trello cards are a good place to ask questions etc. (and can generate email notifications)

define a source of truth

• say you finish your current task and you’re looking for the next thing to work on
• it’s Friday at 3pm, and you have lots of time this weekend
• you ask the teammate with the project management role
• they don’t respond until Monday
• lost opportunity, no?
• recommendation: push project information to a shared source of truth so that anybody can query it on demand
• for example: a spreadsheet, a Trello board, etc
• note: requires discipline from all teammates to keep source of truth updated

pull communication to the beginning

• say we each have a page to do for the web site, and you find a font face and size that you like
• for consistency, it’d be nice if all pages on the site shared the same style
• but that wasn’t specified in advance; what to do?
• probably message teammates and mention your innovation, and request that they copy it
• analogy: inter-thread communication
• not bad (sometimes necessary), but best if it can be avoided by foresight during task definition phase
• other possibility: getting started, then having a clarifying question for client
• might need to “park the thread” of implementation for a while until you hear back
• having multiple things in progress requires context switching and wastes time
• key: do communication during task definition phase (as much as possible)

aim for 2-4 hours of work per task

• how big should tasks be?
• no right answer, but there are some tradeoffs
• too small means you spend a lot of time just managing cards
• too big means you don’t actually see progress very often, which can be frustrating
• (did you really do anything last week, teammate? I can’t tell.)
• in a full-time development gig, I’d recommend 4-8 hour-sized tasks as a sweet spot
• for y’all, I’d shoot for more like 2-4 hours per task
• obviously, estimation is hard, and not all tasks fit that Goldilocks ideal
• goal: steady, visible progress on the project, like tires on the road

poll

Have you used Trello before?

Visit poll.ev/jeffterrell to answer

use Trello (or something similar)

See the Trello board for the Clem project

Concepts include:

• lists (columns) and cards (collapsed or expanded)
• comments and checklists (for tasks or prereqs)
• kanban: moving tasks from left to right
• stages of work, from backlog to deployed
• labels, especially “blocked”
• container cards
• card numbers

Many, many alternatives to Trello exist (e.g. GitHub Projects), but Trello is good and free

poll

What are you currently inclined to use for project management?

Visit poll.ev/jeffterrell to answer

Bonus: hyperfocus

• I actually break even my 2 hour tasks into small steps
• I think this is one reason I tend to be productive and efficient
• demo (if time)
• gives me a psychological/emotional boost to see progress being made
• helps me stay focused, because none of my attention is given to remembering what needs to be done
• getting into a creative flow state is fun!
• I have a video demonstrating my setup if you’re interested

Gathering user stories

Recall the template for user stories:

As a <role>, in order to <goal>, I can <describe feature>.

For example:

As an authenticated user, in order to keep up with my friends, I can see a list of recent posts from my friends, most recent first.

Note the first-person perspective, which helps you focus on value delivered rather than implementation details.

Gather user stories by talking to your client, but remember that the client may have a particular approach in mind that isn’t actually needed (e.g. when the widget I was adding to the web page was auto focusing to the bottom of the page).

To uncover what your client really wants, try to enter their world and see things from their perspective. Try to understand the client’s context.

Here are some questions to ask your client that may help you understand their context (courtesy Arizona State University):

• What is the primary motivation for X?
• What is the key problem that X addresses?
• Why is X important to your company?
• What do you hope to accomplish with X?

The plan for Wednesday

We’ll start learning design principles and tools, so that you will be equipped to create a clickable prototype of the app you’re going to build.