Homework 3: Team Banana_Pie
For this homework, the reviewing team has analyzed a previous project led by Tanner Campbell according to the Best Practices in Computer Sciences guidelines (2014). The project is best described as “Writing software to evaluate the accuracy of shape models via normalized cross-correlation and aid in autonomous spacecraft landmark navigation”, and named by its developer as Cross-Correlation Tools.
Cross-Correlation Tools was first developed (V1.0) as a single, stand alone program. The assignment of Campbell was to subdivide Cross-Correlation Tools into 5 human friendly scripts.
Write programs for people, not computers
A program should not require its readers to hold more than a handful of facts in memory at once.
Designed to be automated, so simple is better approach
Few command line optional arguments
Use is streamlined for adaptable and augmentable workflow processing
Make names consistent, distinctive, and meaningful.
Is consistent (-v -h are consistent)
Nomenclature is meaningful for who uses the project
Make code style and formatting consistent.
All of the software pieces support similar command line arguments
All have similar informative headers
Variable names are consistent
Let the computer do the work
Make the computer repeat tasks.
Automation can be used to run the entire suite.
Save recent commands in a file for re-use.
Use a build tool to automate workflows.
Developer used script within bash.
Automation can be used to run the entire suite, so the computer regularly repeated tasks. The developer saved recent commands into the automation script for readily re-use. To write the scripts, the developer used bash.
Make incremental changes
Work in small steps with frequent feedback and course correction.
Use a version control system.
The developer used own version control.
Put everything that has been created manually in version control.
Own version control used.
In the initial stage of the project, the developer worked within a group for frequent feedback and course direction. After returning for re-development, the developer worked with clients for feedback. While doing so, during both stints, the developer used his own version control.
Don't repeat yourself (or others)
Every piece of data must have a single authoritative representation in the system.
The system is broken down into 5 scripts, each script treats data independently
Modularize code rather than copying and pasting.
Requirements for the project required “stand-alone” modules that were portable. There is still some copy-and-pasting but it was intentional.
Each script has its own purpose and does not overlap in function.
Re-use code instead of rewriting it.
Other libraries would not be applicable, fast enough, or useless for this project. A requirement of this project was to use the least amount of external libraries as possible.
Plan for mistakes
Add assertions to programs to check their operation.
Used for inputs, only going to read in if correct file type.
Various checks along the way to make sure the process is what is desired
Readme for each script explains the input required to function properly creating no doubt about the operation.
Use an off-the-shelf unit testing library.
Not applicable to the project.
Turn bugs into test cases.
Used test cases to revise algorithms, specifically in warped images.
Kept a directory of particularly nasty data sets for baselining code in re-design
Use a symbolic debugger.
Optimize software only after it works correctly
The developer does not agree with the statement above. If you try to build a house on a broken foundation you are not going to get very far, no matter how many times you rebuild the walls. Build it right the first time.
Use a profiler to identify bottlenecks.
The developer knew where bottlenecks would/could be.
Write code in the highest-level language possible.
Used python, but not the newest version
Python 2.7 was used because 3.0+ is silly
Grade: Optimization A+, Following these guidelines: C-
Document design and purpose, not mechanics
Document interfaces and reasons, not implementations.
Uses headers at the beginning of each Python program to explain the usage, output, and example use of program.
Refactor code in preference to explaining how it works.
This was one of the main purposes for the contracted work to revise the software
Embed the documentation for a piece of software in that software.
Along with the comments within the Python programs, A README file is also added in the directory that explains the order in which to run each program and how each program returns data that is necessary to run the next.
No direct collaboration (no one worked on the code except the developer), only feedback from PI
Use pre-merge code reviews.
Pre-merge was not necessary as the developer work with others directly.
Use pair programming when bringing someone new up to speed and when tackling particularly tricky problems.
Used in V1.0
Used Pair Programming sort of during the development of the original project
None in V2.0 project (this project)
Not possible since the developer was alone for the redevelopment of the project.
Use an issue tracking tool.
N/A - paper and pencil
The overall Grade of the project according to the given guidelines would sum up to a solid B.
(However, the reviewers agree that because of the project's outcome and functionality, the grade should be a solid A+.)
The good: I thought we were really efficient with our in person meeting. I feel everyone understood the purpose, usage, and specifics of each program from Tanner's presentation; very well done considering we had a small time window on a Friday. I also thought the organization with the Google slides, documents, and sheets was amazing; thank you Michele.
The Bad: I know there was some miscommunication on whether or not we would present in class, but it was better to be safe than sorry. I also had some issues receiving notifications on Slack and I see that there were issues with viewing comments on Google slides and documents also.
The Ugly: None from me
What could have been done differently?
We probably should have contacted the professor to receive a confirmation on presenting, but our meeting time was very soon after the class where the homework was assigned.