A change in tone, there may not be any pop-culture references in this one. We shall see.
I have recently been writing an iOS app to help Child 2 study for an upcoming exam. It is a simple app which tests knowledge of synonyms and antonyms (look them up). I have form in this area having written something similar back in the day for Child 1. However the Child 2 app has been built in a very different way to the Child 1 app.
Time was very much against me this time around. I started coding in July with the test booked in for September. Last time out, I also wanted to put the end result on the App Store so was painfully aware of how it must look, behave, and which features it must contain to make it stand out. Instead, this time around I decided to focus on a minimum viable product.
Over the past couple of years, I have come to the conclusion that MVP is one of the most danger concepts in the lean canon. MVP’s are subjective – even with often different definitions within the same group of stakeholders. Furthermore I as a technologist will probably have a very different view of what I think the MVP should be to what more business minded colleagues may think. I have even seen occasions where someone on a project will start indiscriminately using the term to describe a physical release – meaning the first thing that gets shipped regardless of what it includes.
Anyway, my goal for the Child 2 app was to get something into his hands as soon as possible to help him learn some new words. This time I started by stripping away the following unbuilt features from my MVP – all of which were part of Child App 1:
- High scores: Quite a nice feature that shows progress and helps motivation, but really not the end of the world if it is not in the first version.
- Select number of questions: Again, handy to have self-contained tests but why not instead just loop through all the available questions. This also becomes a handful if tracking high scores. Which I am not. See above
- Randomising questions: A little bit trickier than it sounds, as you need to start thinking about managing the randomisation and uniqueness of each question. Which I am not going to do here. Why not instead loop through the questions one by one.
- Selecting antonyms or synonyms questions or both: Nice to have, definitely. But really I am after building vocab knowledge across both. It is rare to have a child who can handle antonyms well but not synonyms. That being the case, why not put all questions in the same pot and test on both.
- Help pages: This is a multiple choice app. Who needs help? You have probably got the wrong idea about your app if you need to explain multiple choice first.
- About me pages: I am not even looking at the App Store at the moment, so not worried about marketing in the app itself.
- Google Analytics: As per the above, not going out in the big wide world yet, so why bother. Any feedback that is required can be collected from watching Child 2 directly and will normally take the form of “Dad, it’s not working”
- Multiple views: Child 1 app moved nicely from a menu page to the game to a game over page. However, if you have no menu choices, e.g., to set number of questions, no need for a menu. And who needs a game over page at this stage when you can collect any info you need in a log file?
- Design: Why not use the inbuilt iOS labels and buttons? (Turns out however that adding pictures of rugby players and using colours of Child 2’s favourite rugby team can be quite a motivator)
As you would expect, clearing all this stuff out, has saved hours from the build process. I now have a working version of my MVP that Child 2 is using, rugby pictures and all. Meanwhile I am working on the next features without holding everything back because Google Analytics isn’t working.
A final point to make here. I am generally a hack and more than once I have fallen into the trap of building everything at once. This is partially due to over-enthusiasm, partially due to getting distracted and partially because of concerns about whether the whole thing will come together. However stripping the app down, taking out the above features at the beginning together with careful mocking, stubbing and interface design (e.g., working out what you really need in your .h files) has proven to be an effective way of building something useful in a short space of time. Having a list like the above makes you realise what is important and helps you understand the correct order in which to do them.
This may all be classic lean 101 stuff. But it is a nice reminder to someone who works with agile in large companies that these lean principles work equally well with simple one-person hobbyist projects.
Now, how can I can cram in some cultural clickbait?