Study of Student Software Development Projects

For the last couple of years I have had the great privilege to participate in local university’s Computer Science department’s senior capstone course. This course pairs student teams with a local (or nearby) businesses to work on a “real world” project.

This year I was involved in six separate projects. The software for each of these projects was very different. Because of this, my analysis of these projects is very basic. In addition, we must also realize that these are student teams and that provides a great deal of variation.

BUT…

I think there are some interesting insights we can find in our analysis of these projects. To do this analysis, I ran the Git repositories of these projects through two separate tools.

Gitential was the first tool. This tool takes a project’s Git repository and analyzes the commits, pull requests, and other changes to the code. The most interesting stat is its determination of “Coding Hours” by each developer on a team.

Awesome Graphs for Bitbucket Cloud is a plugin to Bitbucket that analyzes the commit history for a Git repository and pulls out awesome graphs of each developers history over time.

The graph below is the most telling that will feed a couple of summary thoughts on the outcome of these projects.

Outside of the analysis, here is the overall, opinionated outcome of these projects.

• Team A – Good Outcome
• Team B – Good Outcome
• Team C – Rough start, OK Outcome
• Team D – Not Good Outcome
• Team E – Not Good Outcome
• Team F – Good Outcome

So what do we see with each of these teams on the chart compared to the outcome?

• Team A – Good Outcome
  • Highest number of coding hours (four times more than the lowest coding hour team)
• Team B – Good Outcome
• Team C – Rough start, OK Outcome
  • Lowest number of coding hours. Second semester shows two students taking over development to save project
• Team D – Not Good Outcome
  • Second lowest number of hours
• Team E – Not Good Outcome
• Team F – Good Outcome

What is one thing that we can see in common for all Good Outcome projects? What we can see is that all developers are active and working in the project. Those projects have distinctive color bands in the monthly bar charts showing off each developer’s coding hours.

For the other projects, we can see that once group members start “checking out” or “slacking off” it means the project is going to suffer.

When you look at the Not Good Outcome projects, we also see that one student developer buried in work just trying to keep the project’s head above water. But these projects are too large for one developer, and so it isn’t surprising that a single, hard-working student developer cannot produce a good outcome.

Project Summary Analysis

1. Having all developers engage in the project early and take ownership of the project does have a positive effect on the outcome.  For projects where half (or more) developers appear to be disengaged, the outcomes are less positive than the fully engaged teams.
   
2. Good project outcomes seem to require a high amount of effort on the part of the developers.  Low effort will most likely result in a poor outcome.  BUT… high effort doesn’t guarantee a better product outcome as some projects with similar hours/work had both good and poor outcomes.