CAPP 30320 - Software Engineering for Civic Tech

This course focuses on software architecture and design, emphasizing skills and technologies essential for the type of small-to-midsize highly-collaborative development teams common in open source, civic, and public-interest technology.

Course meetings will consist of lectures, discussions, and activities of interest to those working to build high-quality software on restricted budgets and tight timelines.

Putting the theory into practice, you will collaborate on a project with a comprehensive requirements gathering & revision process. These projects will be large enough to experience the kinds of friction that make careful planning, architecture design, and other course topics relevant. The project will also have evolving requirements with the goal of showcasing the advantage of thoughtful interface design.

Students should expect to write a significant amount of code as part of this course as part of a capstone-quality course project.

Goals

  • Develop fluency in common software architectures and patterns, and a sense of when they are and aren’t appropriate to use.
  • Gain practical experience working on a team, building a project with enough complexity as to help demonstrate the benefits of the practices discussed in class.
  • Begin to develop “taste” when it comes to software design & interface choices. What makes an interface or API “nice to use” and how can you ensure others feel that way about code you write?
  • Understand some special considerations that come with working in civic tech/public interest tech, from audience considerations to working within certain common constraints.

Textbook

Textbook: A Philosophy of Software Design, 2nd Edition

This is a short, digestible book that is useful for developers of all skill levels to think about what makes “good software”.

Relevant readings from this book and outside sources will be assigned before lecture to give shared context.

Prerequisites

This course requires completion of CAPP 30122 (Computer Science with Applications 2) and CAPP 30235 (Databases for Public Policy) or equivalent.

Course Information

Days: Monday & Wednesday

Location: TBD

Time 9:00-10:20am

Office Hours

There will be three kinds of office hours:

  • Team meetings, scheduled with each team. A dedicated hour for your team to meet with me. (Required some weeks, optional others.)
  • Discussions. Time set aside for group discussions on topics covered in class, readings, and general concepts.
  • Additional meetings, scheduled as needed: https://cal.com/jamesturk

Course Schedule

Warning

It is essential to be in class in Week 1 to form your team.

If you cannot attend reach out to me ASAP! Preferably before the quarter starts.

Week Monday Wednesday Due
1 Why Software Engineering? Project Teams M0: Project Proposal
2 Human-Centered Design Design Exercise M1: Design Milestone
3 Working on a Team Tools for Working Together M2: Work Plan
4 Writing Testable Code Testing in Practice M3: Git Repository
5 Interface Design Application Architecture M4: Preliminary Documentation
6 Functional Patterns OO Patterns
7 Reading People’s Code Refactoring M5: Prototype Meeting
8 Deployment Security
9 TBD Final Thoughts
10 Final Deliverables

Notes & Readings

Week 1 - Intro

  • What is hard about writing good software?
  • How does working in the context of civic tech change things?
  • How will this course and the project work?

Required Context

Each week, required context should be read/watched before class.

  • APoSD: Chapters 1-3, and 19 - These first few chapters introduce some key concepts about why writing software is hard.
  • Why Software Fails - A short essay on the reasons and ways software fails.

References & Additional Resources

Additional context/alternative viewpoints that might be of interest:

Week 2 - Designing for the Public

  • How do we approach deciding what to build in a public interest context?
  • What are the principles of user-centered and human-centered design?

Required Context

References & Additional Resources

Week 3 - Building Together

  • What are the challenges we encounter working on teams? How can we overcome them?
  • What are common software development methodologies?

Required Context

Why should I care what color the bike shed is?

“The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change.”

via https://bikeshed.org

References & Resources

Course Project

The course project is the core of this class: your means to practice what we are discussing in class and where you should be spending the bulk of your time each week.

As the primary coursework & form of assessment, expect to dedicate the amount of time to this project that you would have dedicated to programming assignments & projects combined in other classes.

All projects will need:

  • To have user-facing & internal documentation.
  • To have a team strategy for git usage and code review.
  • To make use of automated testing and other quality control tools.
  • To meet certain architecture requirements documented below.
  • To come to a consensus on a license for the project.
  • To meet some number of the below optional requirements.
  • Around Week 7, additional criteria will be introduced. This is to mimic evolving requirements and reward careful planning and good architecture.

See the criteria below for more details.

Examples

Projects will be complete public-facing applications built with users in mind.

You can see prior projects from 2025 and 2024.

Here are some example directions to consider:

A public-benefit software tool: A tool that helps communities organize or share collective knowledge. Examples would include tools to help volunteers organize themselves, or interactive applications for participatory planning or budgeting.

A government service prototype: A tool intended to be adopted by a government, or serve as an example of how a government might better provide a service. A redesigned workflow for receiving benefits, or a way for the public to suggest urban landscape improvements.

Providing novel views & analysis of data: A data pipeline to gather & compare energy usage data from different countries, along with tools for the general public & researchers to explore the data. This might include visualizations, simulations, and other features. This is similar to an enhanced 30122 project in some ways, but should be built according to the guidelines of this class: user-first, not data-first as 30122 projects are out of necessity.

Forming a Team

One of your first tasks will be to decide on team roles & workflow.

Team sizes will be determined based on enrollment, in the past it has ranged from 5-7.

A survey and discussion in Week 1 will help us form teams. I aim to have everyone to work on a project they care about in a role that is interesting to them. Everyone will have input but I reserve the right to adjust final teams to meet course goals.

Each non-generalist role should have a primary and secondary team member assigned, this is to ensure that no person is working entirely alone and has someone to discuss decisions with. It also builds in some resilience on the team in case of emergency or unexpected team needs.

Some past team roles:

  • Project Manager: Schedule meetings, design processes to keep project on track, communicate with course staff, work on general documentation.
  • UI/UX Designer: Coordinate design process & feedback loops for iteration. Guide UI/UX design and work closely with frontend teams.
  • Frontend Engineer: Build user interface: web and/or mobile applications.
  • Backend Engineer: Build data model & backend systems/APIs.
  • QA Engineer: Coordinate testing, prioritization of bugfixes, and git repository maintenance and workflows.
  • Specialist:: Focus on a particular portion of the application: GIS, Security, Data Engineering, etc.

One of your roles must be coding-focused: e.g. If you are project manager or UX designer, you should also be a secondary on frontend, backend, etc. Everybody is expected to make meaningful code & non-code contributions.

Note

The goal of having roles is not to introduce hierarchy, but instead to ensure that there is both a decider and a point-person for key areas ensuring deadlocks can be broken and important requirements do not slip through the cracks.

Complexity Requirements

In order to make sure that projects are at a sufficient level of complexity for everyone to have a clear contribution, each project must meet two “complexity requirements” to be agreed upon during the course of the quarter.

Some examples of roughly equivalent complexity are given below, you may decide to meet these, or propose other requirements that you feel are of similar complexity.

GIS Component

Your project makes meaningful use of the GIS libraries and tools.

To fulfill this criteria, the usage must be non-trivial, that is, more than just putting points on a map or a simple distance search.

Examples would be allowing users to plot their own routes on a map, or perform sophisticated area searches.

User Logins / Secure Information Handling

Your application requires users to authenticate. Users might log in because there is some sensitive behavior or information associated with their use of the application. (A log in without any purpose behind it would not count.)

Your application will also be required to have a data privacy and retention policy if you choose this option.

Continuous Data Pipeline

Your application requires the continuous ingestion of data on a regular basis, preferably daily or hourly.

This requirement will mean that you will need to have a functional data pipeline early enough in the quarter to deploy it for a few weeks.

Accessibility

Your application is designed to work well for users with a particular disability, such as vision impairment.

Internationalization

Your application presents its interface in at least two languages using internationalization tools.

Milestones

M1 - Design Milestone

This milestone will have you considering the users of your application before any major design decisions are made.

Potential Lead: UI/UX Designer

M2 - Team Constitution & Work Plan

This milestone will solidify the remaining team roles, key architectural and technology decisions, and set internal goals for the team.

Potential Lead: Project Manager

M3 - Git Repository & Draft Data Model

This milestone will lay a solid foundation for your project to build upon and have you considering your data model.

Potential Lead: Backend / QA

M4 - Preliminary Documentation

This milestone will have you document your architecture & API(s) to ensure the team is on the same page.

Potential Lead: Project Manager / Backend

M5 - Prototype Check-In

This milestone will require a working prototype of key functionality that can be reviewed with time for feedback to be incorporated.

Potential Lead: Frontend / Project Manager

Team Criteria

These criteria are evaluated on the final product unless otherwise noted.

T1 - General Documentation

The 1000-foot overview of the project.

Requirements:

  • A clear & easy to follow README explaining the goals and approach of the project.
  • Public-facing documentation on how to interact with the project. (Can be integrated into the site, a separate document, or a recorded video.)
  • A LICENSE file agreed upon by the team.

T2 - Internal Documentation

If a team member were to join your team in/beyond Week 10, how would they get up to speed technically?

Requirements:

  • A clear & up-to-date architecture diagram.
  • Documentation for API methods.
  • Docstrings on public interfaces.

T3 - User Needs

How well does your project incorporate the needs of the user as stated in your initial exploration and further research? Was human-centered design present throughout your process?

Example Deductions:

  • Product is designed for aging population, but uses small fonts/inaccessible technology.
  • User research indicated that 80% of users would interact with application on-the-go but website doesn’t work on mobile.

T4 - Testing/QA/Performance

Does the application perform as intended?

Is core functionality tested & correct?

Are there any serious issues in the code that should have been caught by testing?

T5 - Frontend Evaluation

Is the user interface easy to use?

Is frontend code well-organized with clean & maintainble code?

The threshold for non-Python code quality is lower than what is expected for Python, but should still adhere to best practices as much as possible.

T6 - Backend Evaluation

Is the final architecture well-suited to the task at hand?

Is backend code well-organized with clean & maintainable code?

T7 - Project Management

Did the team use version control & issue management well/according to plan?

Were changes to the plan documented & discussed with course staff?

Unlike most of these criteria, this is evaluated on an ongoing basis, not just at final submission.

Example Deductions:

  • Team abandoned issue tracker after week 4 with no new plan in place.
  • Team members frequently merge own work, against agreed-upon code review policy.

T8 - Additional Complexity

This will be used to evaluate the team’s implementation of a complexity requirement as noted above.

T9 - Additional Complexity 2

This will be used to evaluate the team’s implementation of a second complexity requirement.

T10 - Team Retrospective

The team, as a whole, will conduct a retrospective on how the team performed, and the effect it had on the final outcome.

To earn full credit on this criteria, the team will candidly assess what went well and what could have gone better.

T11 - Final Presentation

Each team will have a ~10 minute presentation given in Week 10.

Full credit for this criteria will require each team member

T12 - Deployment

The project must be deployed to a live website by Friday of Week 9.

T13 - TBD

An additional criteria will be given after the Week 7 meeting.

Individual Criteria

Each member on the team will receive an individual score for these criteria.

I1 - Team Evaluation

Each team will evaluate the contributions of their teammates throughout the quarter.

Persistent or significant issues will result in a penalty here.

I2 - Individual Reflection

As part of the team evaluation, you will be asked to reflect on what you learned working on your project.

I3 - Professionalism

This is an evaluation of how well you worked with your team and course staff.

Example deductions:

  • Missing team meetings.
  • Unprofessional conduct/violation of team policies.

I4 - Individual Code Contribution

The quality of one’s personal code contributions to the team. Was your contribution to the final product significant & well-written?

I5 - Individual Auxiliary Role(s)

You will be evaluated on how you performed in your non-coding roles (project manager, QA engineer, etc.)

Grading

There are 23 criteria outlined above: 5 milestones, 13 team criteria, and 5 individual criteria.

Each of the project milestones and criteria will receive a grade:

Points Description
0 Failure to submit; significant issue.
1 Fails to meet most requirements, very incomplete.
2 Fails to meet requirements in a significant way.
3 Mostly meets requirements, with some issues.
4 Meets all requirements with no major issues.
5 Rarely awarded. Work that goes above & beyond expectations.
Exceptional Work

This should be thought of as a four-point scale with room for a bonus point.

A 5 may be awarded in a place where a criteria is clearly met & exceeded. A particularly well-designed frontend or implementation of a complex (but needed!) architecture could earn this point in the relevant criteria.

Or, if a team evaluation made it clear that a team member stepped up in a big way, that person may get a 5 for an individual contribution score.

These will be rare and at my discretion. Please do not ask “will this earn an 5?”–I can only award them after I see the work.

Late Policy

My goal with this policy is to keep projects on track, but allow for occasional late submissions.

Milestones will receive a 1 point deduction per 24-hour period past the deadline.

For example: Complete work (deserving a 4) turned in 10 hours late would receive a -1 adjustment, resulting in a 3. That same work turned in at 30 hours would receive a -2, resulting in a 2. After 72 hours the work will receive a 1.

Failure to submit a milestone or criteria is the only way to earn a 0 barring violations of course policies.

Additional Activities

There will be opportunities through the quarter to earn additional points:

  • class participation (>=3)
    • project planning session (Week 1)
    • design exercise (Week 2)
    • general participation (vocal attendance)
    • TBD
  • Ed discussion posts (>=3)
    • prior-year postmortem analysis (Week 2)
    • APoSD chapter discussion
    • TBD
  • code exercises (>=4)
    • testing practice exercise
    • design pattern exercise
    • TBD

Final Grade

Assignment Type Points Available
Milestones (5) 20
Team Criteria (13) 52
Individual Criteria (5) 20
Additional Activities 10+
Total 102+

These points will convert to your letter grade:

Grade Minimum Points
A 95
A- 90
B+ 87
B 84
B- 80
C+ 77
C 74
C- 70

I reserve the right to move these thresholds, but only in your favor.