A new wiki is coming!

This wiki will be locked for editing on Friday, March 13, 2020, while we upgrade to a new wiki. Here is more information about our migration process.

This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Homework 3: Team Banana_Pie


Kyle Strokes

Michele Cosi

Nick Reppe

Tanner Campbell

T.J. Lippincott




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.




(Tanner Campbell)

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

Grade: A 



(TJ Lippincott)

Let the computer do the work

  • Make the computer repeat tasks.

    • Yes

    • Automation can be used to run the entire suite.

  • Save recent commands in a file for re-use.

    • Automation script. 

  • 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. 

Grade: A-


 (TJ Lippincott)

Make incremental changes

  • Work in small steps with frequent feedback and course correction.

    • Yes. 

  • 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. 


Grade: A+ 


(Nick Reppe) 

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.

Grade: B


(Nick Reppe)

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.

    • No 

Grade: B


(Tanner Campbell)

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.

    • No.

    • 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-


(Kyle Strokes)

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.


Grade: A


(Michele Cosi)




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

Grade: D


Final Verdict

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+.)



Presentation at: https://bit.ly/2kBi5sz



Post Mortem

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.