This is a follow on from post from Hacking the Butler, which described an entry for the Singapore IoT Hackathon that I helped with. That post described the prototype we produced, this post will talk about what I learned from the experience.
What I learned
Aligning on the product’s goal is painful but essential
Before the hackathon we had a meeting with the whole team to decide what features to build and how to prioritise them. Within the first ten minutes of this meeting were all aligned on the idea of adding intelligence and connectivity to fitness corners for seniors. That already sounds very specific, so what was interesting is that we still needed many more hours to align on what exactly we were trying to achieve.
The reason was that as we came up with new features for the product they started to cluster in two groups – ideas that were about improving health and ideas about improving social interaction. We were trying to force rank the priority of all of our features, so to make progress it became clear that we needed to decide as a team whether our focus was on making seniors healthier or helping them maintain and develop social relationships. It would be easy to say that the distinction was unimportant and that we could do both, but that would have been a mistake because in many cases the different ideas pulled in opposite directions.
| Health focus | Social focus | |
| Who is it for? | Doctor and carers so that they can track the user | User decides how the data is shared |
| How much information do we collect? | As much health relevant information as possible, e.g. heartbeat, height, weight | Basic information (e.g total steps) is fine for most social features |
| What kind of data analysis? | Complex analysis of performance data to diagnose problems | Simple analysis, e.g. counting steps to unlock achievements |
After some impassioned debate we decided to keep the social focus, which meant that we were able to complete the force ranking of all the features. These were then all uploaded into pivotal tracker and became our plan for the hackathon. I think this was one of the most important things we did because when time gets tight you can’t do everything, you have to make tough decisions about which of your favourite features to drop.
The experience also reinforced something that I have observed in consulting. It’s often not obvious that a team disagrees on the objective until they try to put it into writing.
Most coordination meetings can be replaced with a good feature list
When we got started on the hackathon, the first thing I expected was that we would meet to coordinate who does what. I imagined we’d then split up into our hardware and software teams and spend a lot of time talking about how to interface our work. I then expected that we would break every few hours to check where everyone was at and where we needed to shift focus. In short I imagined that it would be organised like a compressed version of a consulting project.
The fact was that we only had a real “team meeting” when we were almost done with the prototype and it was time to detail out the pitch. We didn’t need to meet – we already had a feature list and rough areas of responsibility, so it was just a matter of starting to tick off the features. We also barely needed to talk to each other, agreeing the interfaces for the hardware and software was actually much less intensive than agreeing how different parts of a consulting project fitted together. I think the difference is because in consulting you are typically trying to answer a question, and as the team’s view of the answer changes you need to coordinate with all the other modules to understand the implications. When you are building something the “answer” is fixed, so you have less iteration and less need for coordination.
Essential features become less essential the closer you get to a deadline
When we first fleshed out the feature list, there were all kinds of things that seemed like essential components of the product. For example we wanted to not just measure how many steps the user was taking but also whether they were taking big or small steps. It seems crazy but at the start that seemed like a vital feature to me. I agreed to put it towards the back of the prioritised list of features but I always assumed we’d get to it. However by the time we had been working on it for 23 hours straight this feature no longer seemed as essential. Because we’d prioritised the backlog, it was dropped automatically – it was clear we just weren’t going to get to that feature.
I think I already understood in a vague way that it’s easy to see a “nice to have” as an “essential”. However, the hackathon gave me a much more visceral understanding of what it feels like for a feature to make this bizarre psychological transition from being an essential part of the most basic version to being an optional extra.
Developing new features is easy, making them work is hard
When I imagined what I would be doing during the hackathon I imagined that I would be spending 90% of my time setting up new features, then 10% of my time debugging them. It was the complete opposite. Setting up the arduino code to post the number of steps the user had taken to the server took me less than an hour. Working out why the damn thing didn’t work took me more than 8 hours. The same was true for almost all the features. Putting together code that should work was quite straightforward, but working out why it didn’t was tough. I think this may be something that gets better with experience (and also because the Linkit firmware is still new).
If you think that asking for help will be useless, then you should probably ask for help (or take a break)
At 2am it was clear to me that I would never get the posting of data to the server to work reliably and that I would let the whole team down by failing to complete the one feature that was both my responsibility and essential for the demo. It was also clear that the whole thing was way too complicated to explain to anyone so that they could help me. It would take me hours to explain the intricacies of my code and the bizarrely unpredictable way it failed. I was pretty miserable.
Fortunately I was also desperate, so I did ask one of the facilitators for help, and although it did take a while to explain what was going on they eventually solved my problem. I should have asked earlier – I wasted a lot of time trying the same things over and over again because I was out of ideas and was waiting for a magical breakthrough.
At a nadir when I was stuck and unable to get help I decided to work on something completely different and design the box for electronics to go in. I had decided that the problem was insurmountable and that since the electronics would now be rendered useless by my incompetence I might as well make a nice box for them to go in. This meant that I got to play with the laser cutter which made me happy.
After finishing the box I went back to the electronics and got them to work. I can’t even remember whether a flash of inspiration came to me after I finished the box. I don’t think it did, instead I think it’s more likely that the problem that had seemed like it must be fixed actually magically transformed into an irritating bug that we could work around.
Making a functional product is more important than figuring out why things don’t work
While I was banging my head against the wall trying to work out the POST request, my teammate was having a similarly frustrating experience trying to get the LCD screen we had brought working with the Linkit. It showed the occasional character but otherwise wimped out. We went over the connections again and again without result. When we finally got help the facilitator said it was “probably a timing issue” and suggested we use a different LCD screen instead.
That’s what we did, but the fact that the original screen didn’t work was a continual nagging itch. It should have worked, why didn’t it? We had the same issue with the RFID – there was no earthly reason why it should work with arduino uno but not with the Linkit, but we just had to accept it and move on. There was even a similar phenomenon for the POST function I “fixed”. In the end it only worked most of the time, and I only had fuzzy ideas about what I had done to repair it and I yearned to know what was stopping it from working “properly”.
It was painful but necessary to make all of these compromises and to keep focused on making a working prototype rather than solving deep mysteries. I can only hope that if there is an afterlife then it will include the complete and satisfying explanation of all your unsolved technical issues.
The devil is in the (unsexy) details
I thought I was going to sabotage the project by failing to get my arduino code to work, but in the end I almost ruined everything because of something much simpler.
When I designed the case I made sure there was (just about) enough room for everything and a well positioned hole for the LCD display. However I didn’t include, or even think about, anything as prosaic as an off switch. As a result when we carefully mashed all of the boards into the case and sealed it with sellotape we had no way of switching it off to conserve the Linkit’s battery. We were smart enough to realise this was a problem, so we made a hole for the charging cable. The idea was that we would keep the thing charging from a laptop USB port until it was time to present.
Unfortunately when the Linkit is in battery mode it won’t charge from the USB connection. I realised this as the other teams before us were presenting. Our device was displayed before the judges and we were not allowed to touch until our pitch started. As the other teams pitched it was starting to blink on and off and then eventually just died. I panicked. We could switch the Linkit into USB mode and run it from the laptop power supply, but that meant flicking a tiny switch on the board. It had taken us at least ten minutes to carefully pack the electronics into the box, there was no way we’d be able to take it apart, flick the switch and reassemble it in the seconds we’d be allowed to touch the device before pitching. To add to the self-flaggelation I realised that it was exactly the mistake I had made when building the zeppelin hat
Fortunately my teammates were more level headed – we got everything ready and performed rapid emergency surgery on the device while the applause for the last pitch was still going on. Complete disaster was replaced with mild disappointment that we had to exhibit it connected to the laptop.
My very specific learning is to always include an off switch. The more general point is to invest time and paranoia in thinking about what can go wrong in a demo, and to focus as much on the “simple” problems as on the complicated ones.
Was it worth it?
It’s probably clear from the length of this post that the hackathon was something of an emotional roller coaster for me. In the darkness of the early morning when it looked like nothing would work I felt like I had made a terrible mistake. When I was watching the Butler die from battery deprivation I felt like I had wasted the time of the whole team. However the elation when everything turned out OK and all the stuff I learned made it a very valuable experience.
Was it worth it?
Totally