The first thing I do when coming onto a new team is read Jira over a glass of wine and assign myself the tickets I think are going to bite me in the ass in 6 months. It’s usually the more nebulous issues with inactive reporters. I especially favorite those that require social engineering to work out the past. Many people use Jira as a storage for great ideas. The problem? What happens if someone leaves? “My amazing designs and thought leadership will live on! I am amazing engineer! I made all the right choices.” No one actually thinks like this, but our actions often proceed us in Jira.
We leave people with our…legacy.
Our legacy choices. Our legacy code. Our expectations. The person coming after will be blessed by our brilliance. Sadly, this shit world does not gift our future owners our magnitude to handle the consequences of our in-progress tasks and our institutional knowledge in their new context and resources. The business morphs too. Dependencies moved forward. Is more documentation the solution? How much? If we write enough about our process…if my manager prioritizes like an immortal god… she can solve the legacy. Right?
There’s a good reason people believe in zero-bug backlogs. It is not because they aim to pay down all the tickets. It’s because living in indecision is living in legacy for the rest of forever. People fear others leaving. They fear other teams forcing their process, their code ideals on them. They fear change. Prioritization isn’t decision.
“Won’t Fix” and “We aren’t doing this ever.” is though. I am going to tell a story about decisions and living with legacy.
Change Happens Because of Business
I decided Ker-Chunk Games, which co-developed mobile games PrinceNapped, Call Me Phrasy, 21 Potions, Nimblitz, and also developed other work for clients needed to shut down in 2019 after 6 years of business. Why? We made all those games and I only started with $30K in my savings. We had no real funding. We bootstrapped with consulting work. While our infrastructure was moving forward and our ability to build games rapidly with limited resources was incredible, our margins were tight for developing games, especially content monsters. It wasn’t going to work without funding and while we had finally reached the point of profitability (’17 & ’18 were profitable) and had people interested (again) to invest, I didn’t feel like it was the right move anymore for the industry. We missed the magic moment of mobile. In 2019, I saw we were going to report a loss. Our business was different from what we had set out to build. It was time to start over.
This was not a decision my cofounder was happy about, despite it being the right decision, but she supported it because she had to. We discussed what the next 6 months would look like and she was able to build her own website for 3 months while still taking a paycheck so she could transition into a new job. Because I made the horrible call, I owned the parts that came after. I looked at all our code bases, our sprawl, our in-progress client work and realized, not “great I now own everything we built!” but “I own the entropy alone and my co-founder can walk away from it.” I took all business responsibilities too and raced time. At that point things really did switch from quality to “tech debt.” If you operate from quality, your customers drive your business. If you operate from tech debt, you just operate from pain.
“Facebook Policy Warning for App: PrinceNapped (App ID)”
Hi Molly,
Could you please update on the progress related to our Platform Policy 8.2?
Our scope is to create a great platform experience both for end users and developers. Given this fact, do not hesitate in future to request a reasonable further extension.
Thanks,
I thought, “This is it. This is the one that forces me to shut down the games.”
PrinceNapped was on Unity version [ancient]. I went back through the client-side code and realized a couple of awful things after trying to build the clients.
- This was not the only game I had to update
- GameSparks (the original version) was throwing errors in another game
- I needed to upgrade 3 full mobile games on 2 major engine versions on my own. Alone.
Hi [Name],
We have submitted a 1.1.0 build to Apple and it is in “Waiting for Review” status. Once it passes it will immediately go live.
Please note that we had to do the following:
- Our build uses Unity SDK 7.16.1 – we were unable to get newer FB SDKs to build in xCode 11 after 7.17’s switch to cocoapods. We tried all SDKs after 7.16.1 and pointing to different iOS pods within the XML dependencies, but still could not pull the pods. We are following the git repository for the iOS SDK for Facebook SDK, specifically this issue and hope an update is posted soon with a fix. In the meantime, we hope Facebook Unity SDK 7.16.1 is an acceptable solution to be in compliance with Platform Policy 8.2.
- We kept Facebook Analytics, but we had to remove Facebook login from PrinceNapped as we could no longer get the login calls to respond in SDK 7.16.1. This game is an older game, so we made the call to pull the login feature in order to save time on our side. Sorry we couldn’t keep it. We also made consent updates so that Facebook Analytics is held from tracking until the user gives consent.
Once it passes review we will turn off login in the portal to reflect this change.
Cheers,
Molly
You read that right. I ripped out Login. This is not a choice any reasonable person in an enterprise setting would do, but me? Definitely. Because this was not enterprise. This was survival. I had left myself with our legacy for the entire business. Ripping out login meant all leaderboards and all levels also would no longer function for new players in the same way. You would have your anonymous ID and score, but no friends. I never got the chance to process emotionally any of this destruction.
I worried for one of the repos we shared with an external partner for an almost finished 5th game, they would not credit the art contractor they didn’t know whose work was amazing because I was the one who cared about managing credits on the website (that game launched under that partner who finished the final bits and bobs). I worried how mad all the former programmers who worked on our games would be. I worried about what to do with the Nimblitz codebase, which, because of it being hypercasual, minimalist, and newer, was well-written by Rukia Brooks and less prone to fossilization. I upgraded around her code. I was severely burnt out trying to manage, juggle these games and telling clients we were no longer going to be in business, but also job hunting. We also still delivered on any SOWs that had been signed. It was a mess. If I made the right call for the business, based purely on the books, why was everything still so hard in trying to move on? I thought shutting down would be easy. There’s no way to not have both technical and business entropy. It’s co-mingled. And while you do it, people really want you to not do it the whole time.
I thought deeply about the time I committed to keeping a bunch of games live because I was trying to be kind. I felt guilty about every choice. Then, I felt inhumane because guilt was slowing me down. I became ruthless. The bank account did not care about my feelings. It just kept having money drain. Meanwhile, vendors were confused about what Pro or Personal version of their product my company should be on and emailed me because I was shutting tools down. At this point, I had bought out everyone. I was the one over the AWS resources. I was going through the whole sunsetting process alone while also trying not to sunset. Any component, any code, any backend left alive was my problem. It was, for lack of a better term, terrible. I was a normal person living with 6 years of legacy (entropy) for a full games portfolio.
My only mission in early ’20: Keep the games live as long as possible and try to keep them cheap without re-architecting. I wrote spectacularly shit code to skip and hide errors. I pulled out entire features. I implemented consent updates because why not. Do right by users if you can and try not to get taken out by compliance and legal on platforms while trying to do right by your former teams. Make sure the binaries still build. Keeping a game live for resumes is so different than keeping it live for revenue. It gives you a purpose that is priceless. Painful. But priceless. I lasted as long as possible in this condition.
If you work with me now: Go ahead, drink a tea. Cheers. When I see codebases that have actual teams that have to deal with sunsetting and are used to the handoffs and process, I understand. This was on me to live with the choices built by many different people over the years among art files, C# repositories, backend, documentation, and only their pain because of a choice I made and was fully accountable.
Watching The Sunset
I was so excited for the day when I finally deleted all the servers for PrinceNapped. I was also happy because both my co-founder and I had found new jobs – COVID had started. The excellent Chud, my partner at Drowning Monkeys, now had full ownership of Call Me Phrasy! so I could move on. It was June 17th, 2020. I can’t imagine what COVID would have done to devastate our business anyway. I remember writing the sunsetting post on Facebook for PrinceNapped to our network and feeling sad and also ECSTATIC.
I don’t have to give a shit about RDS anymore!!!!!!!!!
This is not really a message you can tell your players at the time of actually sunsetting. It sounds like you didn’t care about their data even though you spent the last 6 months caring about data more than anything else.
“Molly! You could have sold the games for millions.” No. Trust me. First, you do not want to buy this code, and I in good conscience would not have sold it to you. In fact, you may not want to buy most code for games that were written around 2014-2016 in Unity. The consulting side was the most profitable – we did not fund user acquisition and did not launch with 300 levels in ’17. We designed a game that we were not staffed to keep up with the consumption of our VIP players who went through 75 levels in a week. Everyone who worked on PrinceNapped, but especially my husband Justin Sheets who wrote a significant portion of the C# code and php, would say, “Yikes. Don’t give me that repo to own” but “It was actually a good game – we learned exactly what the business needed fast.” Meanwhile, I spent most of the time caring about the analytics ingestion side and 3rd party SDKs. I found us Mak Fuse to teach us AWS back in 2014 after we moved from Azure and we built on EC2 and RDS because Lambda was not scalable yet for games. In 21 Potions, Call Me Phrasy, and a few of the panels for PrinceNapped I dove into GUIs so I also know…
Unity GUI didn’t exist when we started building PrinceNapped. Would you like to do a full NGUI rework in the client or is the plan to keep the Unity version the same? No matter how well those who worked on PrinceNapped built anything at all in that game, we could not account for our legacy against dependencies and the choices of third parties to move forward. Now multiply that by more games. New phones. Time and business will always be what a team has to evaluate against entropy, quality, and customers. Customers are what matter. They do not care that we wanted to test some idea we had 12 months ago. They care if it’s fun, if there is enough content, if the product works and solves their use case. Anyone left after the business results are in, is left with business choices around those results. And a ton of entropy.
Business will always be first. Prioritize against customer discovery and teams will hit some of their most important quality issues anyway alongside the opportunities they actually need to stay in business. This kept me in business for 6 years.
A never-ending backlog of ideas is legacy
We should ask: “What really is my legacy? Is it my code? Or is it the way I treat other people to give them a chance to own their destiny by not leaving them with my entire legacy?” Our approach will change. We will care about how to turn people into owners of their own destiny to accelerate business and not force destiny on others. We cannot control another person’s legacy, and we may be left with it regardless, but we can try not to contribute to it by being ruthless and decisive.
We will do things because it’s driven by new opportunities we want to have. And “won’t fix” anything that we don’t plan to do so that we actually deal with entropy before it becomes a never-ending backlog of tech debt. It’s on the team and, by extension the business to make it so we are not the last ones standing.
If you are the last one standing, you owned your legacy and lived.
