What a Failed Launch Taught me About Software Development
In the Fall and Winter of 2017, I built an Android App to control a drone. At the time I was working on a joint venture between a tomato grower and a motley crew of drone pilots, businessmen, and hardware people. We were trying to solve a critical problem in farming. Although farmers have more technology at their disposal than ever before, field inspection was still a manual and labor-intensive process. At the end of the day, if you want to know how this season’s tomatoes are coming in the only way to do so is to go to the field and walk through the furrows. This work was done by field managers who walked the fields with a moisture sensor, soil reader, or other instrument and probed the soil. It took hours to travel to the fields and. walk through them which led to small sample sizes collected. This meant an incomplete picture of the field conditions. Our idea was to make it easier to collect this useful data using drones. My job was to make sure the drone flew to the sensors and collected the data. Through this journey, I learned some important lessons on how to plan and design a project based on end-user needs and the importance of checking one’s assumptions in the software development process.
This was not my first big project nor was it the first time I built something without prior domain knowledge. I had built plenty of apps and websites for various users. Directed plenty of projects to successful launches under stressful conditions. I was confident, this was new and exciting work that kept me up at night. A few months later and I built it, on time, with plenty of automated and live tests — it worked until it didn’t.
The big day came a live test in an actual field in front of all the stakeholders. The drone flew but the app fell like a lead balloon. My teammates put the sensors in the ground and entered the sensor locations into the app. The drone took off and proceeded to miss all of the sensors — it did not stop and read any of the sensors. It was off by several feet from where the sensors were — why? I built the app to accept sensor locations from the users through a map. The user can zoom into the map and tap on it which sets a waypoint that tells the drone where to stop and take a reading. However, there was no way of telling what you clicked on the map was the exact GPS location of the sensor in the ground. It was a catastrophe, we ended up chasing the drone while it flew and planting the sensors where it happened to stop. As you can imagine, I was ashen and beside myself at this glaring oversight.
To my relief, the demonstration went well. We had managed to put the sensors in the right place by chasing the drone. Congratulations for everyone but as soon as I got home I was in a frenzy fixing my crass error. I put added two inputs, one for longitude and one for latitude, into the app. Now the user had the option to enter the exact GPS location. I made certain these GPS coordinates were entered as and stored in double precision. This didn’t even take me an hour to build, it was easy and obvious — painfully obvious! How could I have overlooked this?
In essence, I failed to do my homework and I tested the wrong cases. My research at the onset of the project was centered on the technology, not the user. This was my first time working with the DJI SDK and a DJI drone so I didn’t even know if what we wanted to do was possible. I feared I was promising something I could not deliver and that fear distracted me from asking important questions. I didn’t ask myself “what was I building and how was it going to be used”. I understood who was going to use it and why the app was needed but this modicum of knowledge led to a false confidence which made me too comfortable guessing what features were needed and how they were to be used.
As an engineer, your number one enemy is your ego and its ability to fool you into thinking you can intuit solutions to all the problems you face without leaving the confines of your mind. I failed to ask the end-users how they were going to use the app. I failed to ask them what exactly they wanted to do with the app. So when we did test the app, I was testing a false premise. The app passed all its live tests but the tests never checked if it could do what the end-users wanted. It was a humbling experience but I now am more confident in designing a successful product and lunching it.
Here are the steps I’m taking in my current project to avoid this mistake:
- Research and understand the problem.
- How does the user define this problem?
- Why does this problem exist?
- How does this problem impact the user?
- Where does this problem occur?
- How has the user coped with this problem?
- Understand how the solution you are building solves this problem.
- How does the user define a success state?
- How does my solution lead the user to that success state?
- How do the features I am building map to the problems the user faces?
- Create tests that verify that the solution does, in fact, solve this problem.
- How do I know the features I built solve the problem?
- What metrics or states define success?
There is no order to this. It is by nature cyclic, as you discover solutions to the problem you will in no doubt learn more about the problem and uncover new issues.
To many of you, this may seem like a product manager’s responsibility but it is not. What I learned while working on teams with and without product managers is that EVERYONE is responsible for understanding the product. You can only assure team alignment and product quality when everyone is a product manager. If you are not taking the time to understand the product then you are cheating yourself of an opportunity to improve your work, get more enjoyment out of work, and ultimately have more leverage in your product’s direction. Lastly, too often in a startup you do not have the luxury of a product manager, the software engineer wares all the hats.
