A case study of prototyping bioinformatics software: Ribbon
The way to finish a big software project is to focus on testing the main idea as fast as possible. I applied this idea to finish a prototype of what became Ribbon (genomeribbon.com) in 2 days. It wasn’t very good yet, but it was enough to test the idea that this type of visualization would be a useful way to look at genomic data and understand structural variants. I decided to share the details here and show you what Ribbon looked like after those first two days, and what it looks like now. My hope is that if you are thinking about making your first big software project, that this will encourage you to get started — and to start small by testing your big idea first.
What is a minimum viable product?
In the Lean Startup, Eric Ries talks about how to organize the development of a new product. The core idea is that a startup is an experiment. In this scheme, we should build something called a minimum viable product and test it with customers as fast as possible in what he calls the Build–Measure–Learn cycle. In the startup world, this idea has gained a lot of traction because it prevents the common problem where companies spend years building a product only to find out that nobody is interested. Usually it is because it solves a problem that nobody really has. It is much better to figure that out after 2 weeks of work than after 2 years.
So how does that relate to building bioinformatics software?
Let’s say you have an idea for a bioinformatics tool you want to make. The minimum viable product would be the smallest version of that tool you could make that contains your core benefit and can be tested with your customers. But who are your customers? Even in free academic software, you still have customers. They are the other scientists who would use your tool and cite the paper in their own work.
If you are making software to solve a problem that you yourself are having in your research, then you can start by testing it with your own data and see if it gives you any benefit at all over existing tools, doing it manually, or whatever you normally do. If you are not in the target market for your own tool, then the only way to test it is by showing it to people who actually have that problem you claim to be solving with your software. You may have to scrap it and pivot if nobody is interested, but that rarely happens when you are solving your own problem. By continuously testing the software and making improvements, your minimum viable product transforms into something even better and that is when you can add all of those extra features that you were so excited about at the beginning.
So how do you decide what to include in your minimum viable product?
This video covers the process I went through to create Ribbon, which was the last application I made during my PhD and the first that was purely a visualization tool. I made Ribbon when I was working at PacBio last summer and it was due to a frustration with not being able to see the full information contained within long read alignments, especially around complex variants.