In this post I want to share some of my war stories about scope, and lessons that can improve how you design your software projects.
Software Scope: Lessons from Herd Immunity
My hope is after reading this post you’ll be more enabled to:
- Iteratively develop in order to ship products faster,
- Debug errors in development faster, and
- Understand the technical tools at your disposal faster!
If the term scope seems foreign to you now, I can totally relate — it just seems like a topic that gets scant attention amongst budding software engineers.
However don’t worry, because this post is a celebration. I recently had to make a ton of design decisions in developing my most recent web project, Herd Immunity, and I want to share what I’ve learned with you.
I can name more than one time that this material, that this skill of application architecture, saved my tail and made it possible to keep building my code base; and I’ll be pulling from those examples so you have a better idea of what I’m talking about!
Clearly Define Project Goals
Scoping an MVP
The best analogy I have for explaining scope (as it relates to your software) goes a little like this:
Would you ever set sail on a ship with a sailor who’s lost his tele-scope?
(Dare you to say that three times fast :)
Let me be even more explicit, because understanding the MVP is all about keeping it simple.
Herd Immunity began simply, as a public service announcement: many families today choose not to vaccinate their children, despite a growing body of evidence that shows it has no ill-effects, and au contraire poses a risk to their larger community’s resistance to epidemic outbreaks (referred to as “herd immunity”). How do we show them the evidence in a way that’s meaningful?
So how does having a guiding purpose to your project help you define its architecture? In my experience, it helps because you start defining what’s really important in your code.
Rule #1 to Debugging: Don’t Fix the Problem.
It’s sounds counter-intuitive, but let me explain: preventing a problem is always better than fixing one, and there’s lot of problems in software we can solve by simply taking the time upfront to clearly define how we want something to work.
What to do Instead? Plan for the Problem
For example, during development of Herd Immunity I came across a roadblock with generating pie charts using Chart.js, a popular framework for displaying data on the front-end using a figure, such as pie chart.
The error I had was being unable to make the pie chart, and not knowing where I was going wrong. I had looked through multiple tutorials online, forums, videos, and still couldn’t diagnose the issue. The error message was not being helpful either.
So what do you do in that scenario? At a certain point, I realized I had to face reality — if I kept bashing my head against the wall over this one feature, the overall project would never be finished. The question changed from how to why — why did the chart need to exist on this version of the product?
I had already configured Chart,js to display bar graphs on the front-end — and I realized that they actually deliver the same purpose as a pie chart (which is to contrast quantities across categorical data). So why not just keep with the bar graph and keep going?
The Lesson
Let me leave you with a quote (as best as I can remember it), from one of my Software Product Development lectures at Make School. This comes from Adam Braus, and it’s on what he called the “biggest problem in software”:
The biggest problem in software, is being able to ship anything at all.
If you feel it sounds lame to just give up on a problem, I understand and acknowledge how the idea comes across— and believe me, I totally plan on getting better at data visualization in the future.
Until then, I invite you to consider the benefits of thinking this way, which is what’s called “agile” software development. Going back to Herd Immunity, consider all the other things I had already learned, just by virtue of trying to learn Chart.js: it was my first time using Javascript on my website’s front-end! Along with using the framework itself, I got to learn…
- jQuery,
- Ajax,
- practice my knowledge of the Django REST Framework (my back-end is all in Python)
- and more!
All of that was gained, and what did I lose? By jumping ship on my one pie chart problem, a product is still shipped at the end of the day. Meaning we’ve made it to a checkpoint, something that says we at least made some progress from… well, nothing. At the very least, the project is no longer abstract, it’s no longer just an idea, but something you and I can deal with in our day to day life.
That my friend, is undoubtedly an awesome place to put a stake in the ground. If anything, it provides the best options to continue improving the project going forward!
I hope you will all check out my site: go to Herd Immunity today, and with those whom you think will find it enlightening.
