New this year, we are adding the option to do “Project Extensions,” where you will have the chance to take your completed projects even further towards real-world engineering. Typically when you program for school assignments, relatively little concern is given to many things that are of great importance in production software, such as performance, security, robustness, or maintainability, and this is a chance to flip that around.
In true respect to the complexities of the real world, you can do a project extension on just about any topic. Here are a few facts to possibly inspire some ideas:
- Virtually all first implementations of
keygenwill be vulnerable to timing attacks. - Modern regular expression engines are expected to support capture groups, Unicode, adaptive evaluation strategies, and literal-searching optimized for modern hardware. And many don’t use NFAs, either.
- Ilana the TA’s implementation of
myziptook 14 seconds to compress a test file, whilegziptook only 4 seconds and acheived a 20% smaller compressed size. Both are using a similar algorithm.
The Extension Process
A project extension will begin with a small proposal submitted at the final team meeting of the previous two-week sprint. There, it will be approved or iterated upon, and the final products will be due two weeks later.
Extensions must include in their final products (1) a non-code deliverable (readme, writeup, etc.), and (2) an artifact implemented–some sort of code or analysis that can be explained in the non-code deliverable.
If an extension continues to interest you after completion, you are free to extend your extension. You can also do a second extension on the same miniproject.
The Proposal
The proposal should include
- The aspect(s) of the mini-project you will be investigating further.
- Some discussion of methods you will employ. Will you be measuring performance using a profiler? Doing a statistical analysis? Security auduit? Will you refer to or study a relevant real-world implementation?
- A rough idea of what your final deliverables will look like.
- A list of priorities for inclusion in the deliverable.
- A breakdown of which team members will do what, and what part of that is expected to be done in the first week.
This can be written tersely and need not exceed ~250 words, but should accurately capture your intended scope and plans for the extension.
If your proposal is underscoped it will not be accepted. Each team member has 24 hours of 100-course-level work to contribute to the project, and the proposal should reflect that. Feel free to reach out to course staff with questions before your sprint meeting if you need.