In my app development guide I emphasise talking to people and working on paper as being vital first steps in developing a great app. That coding comes quite late in the process. Yet, I wonder if I’m being honest with you, as that isn’t always what I do. Sometimes I’ll do brief bits of coding near the start of a project. Why? And how do I square that with my general process of people first, second and third, then code?
It all comes down to attacking the greatest risk first.
Back in 2016 I turned up at an NHS Hackday in Cardiff. This is where techies and doctors get together over a weekend and try to make technology that helps in the healthcare. I turned up as an app developer with no expectations other than to encounter interesting people and ideas. It was Dr Michael George who proposed an otoscope simulator. An otoscope being the tool that doctors use to look in your ears. The problem with otoscopes being that you only get a very small view into the ear and have to move the otoscope around to see all of the ear drum and canal. Getting the experience of real conditions viewed in this way is the big problem. Doctors can practice using an otoscope on their friends, but then they’ll only see healthy ears. They only get the full experience when they work in an Ear, Nose and Throat department in a hospital, which only a few do. So the idea was to make an otoscope simulator in a mobile phone. To give the experience of viewing the many different conditions as if you were examining a real patient.
Our team formed of other doctors and engineers with me as the only app developer. Michael was keen on a 3D virtual reality solution, but I was upfront that though I had dabbled in 3D I couldn’t get anything worthwhile done in a day. But I could see a 2D solution. The engineering effort was divided between those looking at the 3D solution and me on the 2D one.
As a young engineer I got the advice to ‘attack the greatest risk first’. The bit of the project that you are least certain about and could trip you up, do that first.
The greatest risk for me was reading the position sensors on a phone, something new to me, then using those to create a display that looked like the view through an otoscope. I didn’t know how difficult these were going to be, or if we could get realistic results. So off I went and learnt about reading pitch, yaw and roll on a phone. I got them displayed on the phone as text, then moved onto using them to make the ‘port hole’ view on a single image of an ear. By lunch time I’d got them both working. My greatest risks attacked and defeated.
The 3D effort didn’t come off. It became obvious that it was a couple of weeks work for someone skilled with the technology. Plus the realisation that the otoscope is held at a fixed depth in the ear and only one eye is used to look through it, so it is fundamentally 2D.
The full team came together on the app and we made a training game of trying to recognise a range of ear conditions. We were one of the few teams at the end of the hackday that could show something working.
After the event I spent a couple of days polishing the app and publishing it on the app store. Six months later Michael and I had created Simulation Sense, the company based on the app, and received a small seed investment and support through winning a place on a start-up accelerator.
So is my general process wrong? I don’t think so. Both are examples of attacking the greatest risk first. In my experience the vast majority of risk comes from the people side of app development. Of making something that fits well with the people that will be using it and will make it a success.
Sometimes there is technology risk too. It isn’t known if the solution is possible or how much work it will be. Attacking that technology risk is known as a ‘spike’ in software circles. Spending a couple of days just to understand the risk and work through it or around it.
Our time at the hack day was a spike. We cleared up a lot of technology risk very quickly. It only took a few hours of intense effort to find out that 3D virtual reality was going to be hard for little benefit, and that the attitude sensors could be easily used for a 2D solution. That is a good use of a day’s effort.
At the end we had a technology demonstration, not a successful product. After forming our company and joining the start-up accelerator I wouldn’t do any more coding on the app for months. Those months were spent researching and working with our potential users, the people most important to making it a success.