As developers we’re often told “Don’t try to write one of these yourself, it’s already been figured out and done for you.”
This advice holds true for a lot of things. You don’t want to write your own versioning system, or IDE, or sorting algorithm in most cases. Each are huge projects that probably aren’t relevant to making your software good.
Writing good software requires you to focus on the user & improve their experience the best you can. A user doesn’t care what sorting algorithm you’re using. They care that their list is in alphabetical order and that it happened fast. There are plenty of fast sorting algorithms out there to use. Don’t write it yourself.
Some features are more complex, maybe even integral to your software, and the user needs them to be good. This is where you start to decide if you should write the entire stack of that software yourself.
For example, I maintain the watchOS app Should I Run. Should I Run takes the user’s location and finds the nearest Metro station. This operation needs to be fast because it happens as soon as the user opens the app.
At first I tried just loading all of the Metro stations into memory from a SQLite database I had built, and searching through all of them. It was a quick and dirty solution. It worked, but it was incredibly slow. Opening the app would take a long time, which is a horrible experience for users.
I looked around for databases with geospatial indexing, and I found mongoDB Mobile. It offered geospatial indexing, but it would have tripled the size of my app. For such a small amount of data, it didn’t seem worth it.
So what did I ultimately land on? Well I did a lot of research on how geospatial indexing works. It turns out there are a lot of different data structures you can use, but the one I managed to understand was the R-Tree. It allows you to find the nearest point to another one. Great!
I looked around for R-Tree implementations in Swift (I really didn’t want to have to deal with C). There were two. First, Apple has an RTree implementation that is entirely in memory and doesn’t support saving to disk. Womp. There’s another in-memory implementation that is self described as “A terrible attempt”. And that’s it.
So what now? All of the R-Tree implementations don’t meet my requirements. And this is an integral part of my app! It was time to write it myself!
After a lot of learning I published the library RTree. It took a bit of time, reading some papers but it meets my requirements exactly. And it does it in a few kilobytes, rather than tripling my app’s size. And it’s quick! The R-Tree only requires opening a file handle and seeking to offsets, so it’s incredibly fast.
By writing my own library I managed to meet my requirements exactly. No other solution would have been as efficient, and now I know exactly how my software is working under the hood. I couldn’t be more pleased with this solution.
Writing your own solutions to the most important aspects of your software can be incredibly beneficial. You can get solutions that perform better, and make your customers happier. But it’s not always the right thing to do.
Writing your own solutions can cost you a lot of time. So you have to pick and choose where exactly writing your own solutions will be the most beneficial. Otherwise, use someone else’s code. It’s probably just fine.
Ultimately choosing to code it yourself is an art. It’ll make you grow as an engineer, it’ll cost you time, and it’ll make your user’s experience better. Remember that writing your own solution is always possible, and it may just be the right choice for you and your users.