HTP!m 2023 Status Report

I’ve been meaning to get to writing this post for a while now. I was heavily burnt out in the final weeks of the project and had to take some weeks of rest afterwards, but I’m finally back with the status report of how “Hack the Planet! mini” (HTP!m) went.

This status report will be detailing the entire project from start to finish, the difficulties I encountered along the way, and the things I learned.

Note: this post was uploaded late. Sorry! I forgot to rebuild my site after posting.

“Hack the Planet! mini” 2023 Outcome

It was a great success! While we were only given a 2-hour time window, we ended up accidentally going overtime as the players were so engaged and glued to their seats. Almost all the teams got at least one target, and one team even managed to get all three targets.

The Failure of Local Learn Day

The marketing and logistics of the parent event were unfortunately a failure. HTP!m was invited to be a part of HackMerced’s Local Learn Day 2023; this event was just one part of the larger parent event. The parent event, frankly, failed to fulfill their end.

For reference, I helped organize Local Learn Day 2021 and 2022. I graduated in 2022, and am no longer an active member – I was just asked to do something for this passing Local Learn Day as an alumni.

In previous years, we’ve been able to amass audiences that nearly reached the maximum permissible limit. This year, they couldn’t have had more than a couple dozen attendees, the vast majority of whom ended up only attending Local Learn Day to go to HTP!m. While I’m flattered that the bulk of the attendees came to LLD only for HTP!m, this represents a greater failure in the parent organization to sustain and maintain operations that supersede community interest revolving around my work.

Imagine if I had said “no” to the request for me to host something. Local Learn Day would have had a disappointing, miniscule number of attendees. If the majority interest around your event revolves around someone who’s an alumni, your operation is unsustainable and doomed to fail. Effective organization and leadership should avoid having a single point of failure that’s in no position to be relied upon.

There are a variety of reasons for the failure of the parent event. I believe it can be boiled down to a few points, and I hope readers of this post can take note of this so that their own events can avoid similar failure:

Notice how each of these failures is non-technical. You can be an absolute genius but if you don’t know how to touch grass, communicate, and work effectively in a social setting, your event is doomed to fail.

I’m glad that a bunch of people came to HTP!m but I’m disappointed that we didn’t get more people, especially considering the immense amount of time, effort, and money that was sunk into the project. I was fully expecting a packed room as we’ve had in the past. The current organization team messed up, didn’t market, didn’t reach out, and didn’t connect with the local community. As cool as my project was, pushing to debut HTP!m at LLD was frankly a waste of my time and effort.

I’ve had multiple conversations in the past weeks with students who wish they were there, but had absolutely no idea that the event was going on until I, someone who’s not even on the team, had just then told them about it.

Anyways, now that I’ve gotten the failures of the parent event out of the way, it’s time to get back to talking about the struggles and successes of HTP!m.

The Development of HTP!m

The development of HTP!m started out smooth but gradually became more and more rough, eventually culminating in an extremely stressful crunch week leading up to the event which I’d have liked to avoid in retrospect. This ultimately ended up in having to scrap a few core components that I’d have liked to keep, putting the project at risk of instability in favor of being able to deliver a minimum viable product on time.

In general, I tend to organize the hell out of my projects. I lay out requirements, specifications, and timelines, and then deliver on implementations followed by documentation. I largely attribute my prior successes to these habits. This project started out no different.

I did not expect the current HackMerced team to want to have a hand in my project and frankly, in retrospect, I do regret not having stopped them. I initially expected to be doing this project solo. Porfirio, the current executive director, hit me with a curveball at a meeting when he said that anyone interested in the project could talk to me. While I was not closed to the idea of working with a team, I simply just wasn’t asked beforehand if I was looking for more hands, because I was not. Thus, suddenly having people wanting to be a part of this project took me by surprise.

I laid out to everyone then and there that my projects can be a bit extreme, and they’re not for the faint of heart. I made it clear that this was not a challenge – this was a disclaimer.

I ended up with 4 teammates: AD, NI, IP, and JL. I spent the first week fully planning out the project, the direction, and the timeline with these teammates in mind. Our fates were now coupled. I relied and depended on them to get their tasks done, and they relied and depended on me to give them guidance and direction. The project relied and depended on us operating fully and functionally.

In the first few weeks, I got a bunch of electrical engineering done and recruited their labor for assembly of HTP!m MODCOREs and parts of the HTP!m CONTROL, the former being an overglorified microcontroller with shift registers to actuate power and the latter being essentially the centralized state controller. For those who had technical skill, I had additionally assigned them to some technical tasks.

The first few weeks went well. We were on track and delivering our targets left and right.

Our tech stack involved Flask, and JL volunteered to take on the task of developing the backend for the platform despite not knowing much Flask. He set up a shadowing session with me, modeled off of my examples, and developed a great backend that was able to be used after just a few bug fixes and adjustments.

AD volunteered for a few infrastructural tasks and although he didn’t have much experience with infrastructure, he likewise set up shadowing sessions with me and we were able to learn and deliver. AD also volunteered to help me create the challenges despite his inexperience, and also set up meetings with me so that he could learn and deliver on his tasks. We ended up making a few cuts to some of the challenges, and one of the challenges was removed entirely so that they could be more doable.

NI volunteered to create 3D models that could be printed for the city, which I’ll get to later.

I continued work on all fronts as well as maintaining the management of the project to continue moving forward, which I’ll also get to later. I also took on the brunt of the work with the HTP!m CONTROL and HTP!m MODCOREs, which involved a lot of electrical engineering and firmware development.

A few others from HackMerced, who weren’t formally a part of the HTP!m team, also contributed to the project significantly. Athena basically implemented the entire platform frontend and Alisson created the frontend for the web challenge.

So yes, the first few weeks went well. We were hitting our deadlines, moving forward, and adjusting the plan wherever necessary based on new discoveries.

As time went on, though, problems began to emerge. NI kept pushing back the task of making the models and kept missing their deadline, and continued making excuses and giving false timelines. Observing and inferring based on the pattern of their progress, I’d concluded that they weren’t really working on their task at all at most times. We relied on them to get the 3D models done since the construction of the city revolves around having an actual city. At times, NI ghosted the project entirely, didn’t respond to messages, or couldn’t deliver on the minimum specifications for the models that they did end up making.

This is where the project began to collapse. We relied on each other to meet our deadlines. NI ended up pushing the project back so far that I had admittedly finally ran out of patience, and I did something that I was not proud of: I cut them from the team and took control over the models; I gave them no further tasks. This was uncomfortable for me to do, and this was obviously not an ideal outcome.

I ended up being unable to complete the HTP!m CONTROL as a result since my time had to be reallocated to picking up NI’s tasks, which were more imperative. I made the decision to change the project’s plan to rely entirely on software from the Raspberry Pi itself. Dozens of hours of intellectual labor taken on by myself, plus dozens more hours of laborious soldering and assembly taken on by the entire team, all to come towards the HTP!m CONTROL, were all for naught now that I couldn’t make the final stretch in its completion since my time had to be reallocated to picking up the task of creating the models.

Catching up on four weeks of missed work in a single weekend, I pulled all the models from the Internet and got them 3D printed. With help from Athena, Alisson, and Sam, we were able to take on and complete the ginormous creative and laborious endeavor that was construction of the model city itself. After a week of painting, drilling, sculpting, and plenty of glue, elbow grease, and model grass alike, we were finally able to deliver on the model city with less than a day to spare. I did the wiring that night before the debut, which carried all the way over into the day of the event itself; I hadn’t slept.

But we delivered. I couldn’t believe it. We delivered.

Photo of the set at the event.

Sample platform shown.

A Lesson in Management

Those final weeks were extremely stressful for me. I was losing sleep, burning out, and was not doing well. At times, I was even considering cancelling the entire event because I had lost faith it could be completed.

Frankly, it was my own fault. I believe that failure comes from above and success comes from below. Because I was too much of a pushover, I let tasks linger to-be-done even after they were long overdue, and I kept being complicit with deadline pushes.

If I had simply been more firm and strict from the start, I wouldn’t have had to partake in such a stressful crunch, wouldn’t have had to reallocate my time to taking on undone tasks, and the HTP!m CONTROL that the rest of us had worked on would have actually been able to come to fruition. As a direct result of my own inaction, the fruits of my teammates’ labor could not be harvested as well as I’d have otherwise liked.

Good leaders need to be comfortable with making difficult decisions. I made mine too late. That resulted in many hours of my teammates’ work going to waste and weeks of stress for us and the borderline cancellation of the entire event. That’s on me. This was a valuable lesson for me.

What’s Next for Me

Well, my next big project is IrisCTF 2024, so that’s my primary focus for the next few weeks. I’ll be revisiting “Hack the Planet!” and Badger next year.

I still have a lot on my plate. Lots of hacking. Lots of making and breaking. I’ll tell you all about it in the weeks to come now that I’m less stressed out and overexerted.

The holidays are coming up soon and I’m going to be visiting my family down south for a bit, so I might feel a bit contemplative and make a personal post or two in the weeks to come. Until then,

Happy hacking!