Weekly Journal : OOLALA Project Analysis

Follow effective action with quiet reflection. From the quiet reflection will come even more effective action. — Peter Drucker

This analysis is your opportunity to demonstrate your own thinking and knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. If it is also an honest and thoughtful retrospective, it can also help you identify specific actions you can do to improve future projects.

Submitting your Work

Peer Team Review: Submit this Google Form, in which you will evaluate yourself and your other team member(s) as a tool to help improve everyone's experience with group work.

In your individual portfolio_NETID repository in the course's Gitlab group, push the following:

• oolala folder:
  • Example: a Logo or L-System program and video that shows off something interesting about the project
  • Code Masterpiece: Java file(s) showing an example of well designed code you wrote during the project
• top-level (as usual):
  • Design Review: a Markdown file, named week07_oolala_analysis.md, with your reflection on the project's design

Specifications

Peer Team Review

Review your teammates and yourself to determine who has been active and cooperative and to help those who have not improve for future projects. In general, your evaluations will not directly affect other members' final grade but will let members know how their teammates view their contribution to the project so they can adjust effort and behavior as needed (if nothing is reported, then it will be as if everything was as good as possible). It is their response to feedback, whether or not effort is made to improve as a teammate, that will affect the final grade. To give everyone the best chance for success, please rate your team members as honestly, accurately, and consistently as possible.

Example

Create your own "interesting" example program for an applications and record a 40-60 second video showing it and the result of running it in your project (provide a voice over on the video to describe what makes your example interesting). Go beyond a simple test example or starting configuration to show off important features or design elements by focusing on creative or powerful things your project can do.

The easiest way to make a video of your running project is to start a Zoom call, share your screen, start recording, and talk over your demo. There are also many free screen capture tools available or free trials of commercial tools.

Code Masterpiece

Choose part of the code you primarily wrote that you feel demonstrates what you think of as good design, totaling approximately 150-300 lines (including comments). It should represent a feature or component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. The term "component" is used rather than "class" because it may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes. Note, if your component is specifically intended to be superclass, it must include enough detail that it is clear how to extend it and at least one example subclass to how it supports an abstraction.

Every line of code in the class(es) you submit will be reviewed, you cannot specify only part of a class or comment out large sections of code. Simply copy only the Java code files you want us to review without renaming them from your project to your portfolio, into a folder named oolala, (you do not have to include files they depend on as we will not be compiling these versions, just reviewing on them).

Design Review

Explain your view of how your program is organized and why it was done that way. This can be an opportunity for you to describe how you might fix a problem, conceptualize something you thought about but could not figure out how to implement, or present an alternate design if you did not agree with the team or did not have time to actually change the code.

If you think something is good, justify your opinion. If you think something is bad, justify your opinion and suggest how to improve it. Use specific code examples and supporting reasons related to design principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, no design is perfect so including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.

• Overall Design. Reflect on the entire project by reviewing all the code, especially parts you did not write:
  • Describe everything that needs to be done to add a new application command to the project (including data files, new code files, updated methods or data structures, etc.)
  • Describe how to implement one feature from the assignment specification that your team did not get a chance to in a way that follows the Open-Closed Principle as well as the project's Design Specifications (or any further refactorings still needed)
  • Review two features another teammate implemented in detail — one that you feel is well designed and one whose design could be improved:
    • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
    • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Your Design. Reflect on the coding details of your part of the project:
  
• Describe a design challenge you wrestled with:
  • What are the trade-offs of the design choice?
  • What alternate designs did you consider?
  • How did you eventually handle it?
  • Why are you satisfied or not with the final solution?
• Describe two features you implemented in detail — one that you feel is well designed and one whose design could be improved:
  • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
  • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Conclusions. Reflect on what you have learned about designing programs through this project:
  
  • What part(s) of the code did you spend the most time on (e.g., debugging, adding to, rewriting, or even just thinking about)?
  • How has your perspective on the practice of coding changed because of this project?
  • What specific steps can you take to become a better designer in the next project?