Minimum Viable Product for the Over-Achiever

Posted by e-be-walk on September 8, 2018

Note: MVP does not contain sprinkles

I am nearing the end of my Flatiron Immersive. Over the last two weeks I have been working on my jQuery Rails project. Project #4/5. After this there is only two short sections of curriculum and one last project- the end is indeed in sight.

In approaching this project, I had some very big ambitions. My app will eventually be deployed as part of the website at the museum I work for. Aside from my simple portfolio site, this will be my first live project. I met with some instructional support to get a better understanding of one of the requirements and to see how I could retro-fit my project for my deployment ambitions in a way that made sense with the requirements of the project. I told my instructor about what I hoped to integrate and what I hoped to remove from the final deployable product.

At that point, my instructor cut me off. He pointed out that though I could manage to do both, it would take some time and would be somewhat disjointed- the requirements of this and the previous segment of the project just didn’t make sense in what I hoped the final product would eventually be. He provoked me to consider MVP. The idea would be to nail the requirements to get through project review, later scrapping all the stuff I had, starting over for the final project to have a really strong deployable product minus all the weird stuff, allowing me to avoid navigating all the redactions necessary, and probably saving me a lot of time and frustration in the long-run.

It wasn’t the first time I had heard the term ‘MVP’ that week. It was brought up at my GDI meet up, again at work, and finally by my instructor about my project. It was oddly symbolic- third times a charm, right? The more I worked out what needed to change in my app, the more it made sense. That, and, I am completely strapped for time and money. Though I had heard ‘MVP’ numerous times before, this was the first time I had really internalized it.

So, what exactly is Minimum Viable Product? The term MVP was first used by Frank Robinson, later popularized by Silicon Valley entrepreneur — Steve Blank, and writer of The Lean Startup, Eric Ries. Basically, you want to find a balance, introducing the minimum product without too much risk or investment but also accomplishing the desired functionality or features. In terms of agile development, this is a great way to get the ball rolling, to get customer feedback, and to inform future product development. In my case, it means doing the bare minimal- producing a product with just enough features to satisfy the requirements of the project.

The MVP Cycle

This sounds ideal and easily accomplishable, right? I could power through this and move on in the curriculum in no time. I could really craft my final project into exactly what the museum wants. If I could just get through this. Five easy little AJAX requirements. It would be a great practice in agile development, helping me reflect on how a startup or development firm might tackle an issue or client request.

As great as that all sounds, I found that minimum viable product was a challenge for me. I’m a bit of an overachiever and have been in the habit of doing things to the nth degree. I tend to be hard on myself and operate in the way that anything worth doing is worth doing right. Why clean the bathroom when the rest of the house is dirty? Why have one college degree when you can have four? Why work on a project that you no longer like, or that is screwed up in a variety of ways if you’re not going to fix it?

In sum, there were a lot of things that I already hated about my project. Though I love the idea that the final project will help my museum, I have literally no interest in the topic my project was written around. Some of my styling was pretty clunky, some of the functionality I had used was already not really making sense for what the museum would eventually need, and just in general there was much room for improvement.

As part of our project reviews, we are often asked to implement other features or do some live coding. As a result, there’s a lot of additional stuff in my project that is unfinished, only semi-functional, and never really aspects I wanted in there in the first place. I don’t want to take the time to fix and remove all this but I do want to think about what I might be asked to do for this segment. Being that my project is in a pretty slapdash and haphazard way at the moment, I’m not sure what I could possibly demonstrate.

This project was heavy in implementing AJAX calls and dynamically updating the DOM. Within my project, I used functions to bind specific click events. The click handlers work to display an index of either one model or another depending upon which link the user clicks. If a user is looking at the parent model show page they can click to advance to the next record without refreshing the page. The user can also look at the parent model show page, and click handlers help to dynamically display instances of child objects that belong to a specific parent. Finally, a user can add children to the parent model creating the resource and appending it to the page without a refresh. I could probably be asked to serialize and display another child model but then I’m crossing back into the weird stuff that I never really wanted as part of my project in the first place.

In my project these models are sites and their children are stained glass windows. So you can filter the index either by sites or by windows. When you click on an individual site, details about the site are rendered via JSON and AJAX. This is where you also have functionality like advancing the record to view the next site, to dynamically load the site’s windows to the page, or adding a new window altogether.

One thing I wish I had anticipated was that creating a resource with images is problematic. My earlier version of this project which relied on Ruby on Rails used a gem called paperclip to store images in the database when a new model was created. Because I am now using AJAX and an ActiveModel Serializer to add the newly created child model, it can no longer hold onto the image. As soon as info is serialized to be add a new model, the jpg is severed from the record. Though there are plugins that assist with this and it seems like it would be easy, I’m still shooting for minimum viable product and have to restrain myself from taking the time to figure out implementation.

Now that I’ve checked all the requirements off, I’ve almost been procrastinating turning it in. I’m not typically the type to procrastinate. It’s been a truly hectic week and even though I very much need to wrap this up, there’s some reason I’ve been avoiding it. The simple fact is that I’m not proud of what I’m turning in and to have spent this much time on something you’re not proud of — well, it sucks. In some ways, even though it’s difficult to be turning this in as it is, it’s comforting to know that I’m not spending too much time on it because there will be an even better finished product ahead. I know what I want to achieve for the deployable project and I look forward to starting on it. I guess in that way, if nothing else, I have truly achieved the MVP cycle.