At one point in episode 112 of Under the Radar (Ideal vs. Pragmatic), Marco and David talk about a dilemma that developers sometimes face: the choice between making an assumption, and exploding complexity. I thought I’d write about some of the times I encountered that fork in the road while building Snapthread, and how I decided to handle it.

My first opportunity to explode complexity reared its head the moment I selected File —> New Project in Xcode. I was immediately presented with the option to use Core Data. I stared at the empty checkbox. Did I want to persist data in Snapthread? Should my users be able to save their projects in order to return to them later?

Data persistence adds a huge layer of complexity to even the simplest apps. If I had decided to let users save their projects, I would have had to save an enormous amount of information in order to later reconstruct a video. And what would happen when I made the app universal? People would expect their projects to sync. I’m writing this post in Writemator 1.0, which doesn’t yet sync via iCloud, and I already wish it did.

In the end, I assumed that Snapthread’s users could complete their work in a single, short app session. They would open Snapthread, throw together a quick video in a matter of minutes, save or share it, and move on. Of course with this approach, Snapthread will never be a pro-level video editor, but that’s fine with me. It saves me a lot of work, and further emphasizes that Snapthread is meant to be fast and casual.

I made two more assumptions later on in Snapthread’s development: 1) that once I positioned the app as a visual studio for Live Photos, people would primarily use it for Live Photos, and 2) that if users did merge standard videos, those videos would be taken with Apple devices. Scaling and translating videos to work in any of 5 possible aspect ratios requires a lot of conditional branching statements. Each possible orientation (portrait, upside down portrait, landscape home button right, landscape home button left, and then all of those options again for the front camera…) ends up needing different translation values in order to position the video correctly. By assuming that a video’s original aspect ratio and pixel dimensions fall within a narrow range of choices, I prevented that tangle of if-elses from becoming completely unmanageable.

Honestly, I think one of the only safe assumptions you can make in software development is that at some point, someone is going to use your product in a way you didn’t anticipate. You can then choose to either address those edge cases, or say “sorry, you’re out of luck.” For instance, apparently you can’t add a soundtrack from your music library in Snapthread if your phone is jailbroken. There’s nothing I can do about that, and if there was, I probably wouldn’t do it.

I also think that if faced with the choice between making an assumption and exploding complexity, you should almost always choose the former. Incorrect assumptions can often be remedied, but it’s hard to dial back complexity. Just look at all the extra crap Facebook has added to Messenger in the past few years. Even if they wanted to simplify the app again, it can’t be easy to tear all that stuff out.

Anyway, it’s something to think about. What are some assumptions you’ve made while developing your apps?