Observations from the Strength as a Service Intern Team

As the summer begins to wind down for our intern teams, we asked that each one write about what their team worked on, what they learned, and how this experience will affect the remainder of their formal education. This post is from the Strength as a Service (SaaS) team embedded with EliteForm. SaaS team members are Andrew Koerner, Caitlyn Bales and Neema Bahramzad.

This summer, our team created “Strength as a Service”, which allows users to pay for StrengthPlanner on a per year, per athlete basis within the StrengthPlanner application. It also allows for trial subscriptions to let coaches try the software free for 30 days and gives small schools the ability to use the product without installing PowerTracker units.

Our team has been able to accomplish a lot this summer. We developed a product for EliteForm that they will be able to use by the time we leave. Since initial development was completed ahead of schedule, we were able to implement additional features that our team leaders didn’t expect us to complete. In order to allow users to pay for athlete licenses, we had to do a lot of in-depth research on how best to implement payment processing from within the application. This gave us a greater understanding of how companies use payment systems and the pros and cons of using different payment engines. When we were not busy coding, we were maintaining the high score in Jurassic Park pinball.

But it was not all smooth sailing; we encountered our fair share of challenges along the way. Adding trial and payment logic to a piece of software that already existed forced us to work with a pre-existing code base. We spent a lot of time ensuring that our code would not interfere with the main EliteForm branch while creating logic that would make use of the existing features in the system. We also realized the importance of iteration planning. Because we did not fully plan for edge cases in our product, we ended up committing to design decisions that were changed again and again. This slowed down our production and introduced the risk of bugs in the code. It also led to disagreements over the committed implementation. We tried to manage our workflow efficiently so that everyone had enough work to do and accomplished tasks in the correct order and in a timely manner. Sometimes this was difficult when people left for vacation or unexpected roadblocks popped up.

One weakness of our team was testing. We could have written more unit tests to improve the quality of our product. Even with the unit tests we had, we often committed code which broke our unit tests. If we had slowed our development rate and spent time testing the code, we could have avoided a lot of end-of-summer bug fixes.

It did not take long for us to realize that JavaScript sucks and that it either needs a massive overhaul or to be killed completely. A lot of our strife came from fighting with JavaScript to get it to do what we needed. Another realization came from our research on payment processing. Many businesses use payment engines without realizing that they are assuming some responsibility for users’ data when processing credit cards, which many times prevents them from being PCI-compliant. With this in mind, we were able to find a solution that kept users’ credit card information secure. We also busted the myth that PayPal is the right solution for everyone. They are a bulky company that has a lot of different products, making them rather poor at a lot of different things. In addition, they have a lot of up-front costs and unclear documentation. We chose Stripe for its security and simplicity and this relieved a lot of potential headaches.

We are grateful for all the help we received along the way. There are several people we would like to thank individually:

• Cody for creating the account management pages – we couldn’t have gotten that feature implemented without his beastly UI and knockout skills
• Russ for generating email content
• Bob for creating UI mockups for our ever-changing registration pages
• Todd for running iteration planning
• Rich, Nick, Nate, and Ben for answering all of our technical questions
• Ganz for harassing us until we got a green build
• Chris for breaking our code and exposing bugs
• Brian Zimmer for modeling as a typical user and testing in IE
• Jennifer and Amanda for keeping a fully-stocked kitchen
• The Coach’s Tablet team for setting an example of what not to be 

Although we got a large amount of work done this summer, we could have made several improvements to improve our code and our velocity. We should have all agreed on workflow, process and UI decisions before implementation. This would have prevented us from redoing code and arguing over the “correct” implementation. We also could have developed better if we slowed down. Because of our rapid pace, we often did minimal testing and neglected our code coverage. If we had taken time to test and deploy our code after we implemented the trial logic, we would have ended up with a more solid product.

Working on EliteForm this summer has given us a lot of development experience for the future. The three of us will be working on either Design Studio or Senior Design this year. We learned quite a bit about how to plan, manage, code, and test a product, and we’re confident that our experience this summer will help us this year. Although these are things that can be taught in school, they don’t become mastered skills until they are executed on a project.

There were times when we got to take a break and have some fun, too. We went to the Ndamukong Suh Strength and Conditioning Center to help Hari set up PowerTrackers on the racks. It was great to see exactly how these systems were being used and what kinds of hardware go into this product. We went to the Lincoln Children’s Zoo to help out on Endangered Species Day, stole a pickup truck from Steve’s house, watched Nate get cheeseballed, and played massive amounts of pinball.