For me, there’s no such thing as too much planning. When I travel, I pack 3 or 4 days early, to make sure I don’t forget anything. It’s a little extreme, I know, but hey, I haven’t forgotten anything super important in 15 years of traveling on my own!
I’m writing this blog post because while I’ve seen some good answers to this question around the internet, they’re all scattered around in random places, hidden in stack overflows and under various neglected corners. This is an attempt to consolidate all the information I’ve found and stick it in one place.
When I’m building something as potentially intricate as a rails app, I sure as heck want to know beforehand EVERYTHING I’m about to do.
So it comes as no surprise that I have a keen interest in what the ‘best’ way is to plan out your app. And yes, I’m aware of the ‘draw out the path of your app’ way and the different visualizing applications out there designed to help you solidify your plans, but I wanted to know if I could go further with it. Is there a truly foolproof process? One that is repeatable as well as documentable?
Here’s what I found:
There seem to be three big questions (hereafter referred to as ‘the big three’) people ask when discussing app design, and these are: Do I plan out the Front-end/User Interface or the backend/models first? When should I start testing? And how do I make my app as efficient as possible?
UI or Backend first?
Of course, this falls to preference, however there seems to be a common thread: Anecdotally, those who started with the backend and left the front end for later found that they had to do significant refactoring later on, mainly because it turned out that the way users were going to interact with their app didn’t fit into the rigid constraints of their models and associations. User interaction, like human beings themselves, are not so easily encapsulated. This is one reason why they’re fun to design for (as opposed to cats. Have you ever designed an app for cats? Oh my GAWD) but its also why this aspect of app building is so difficult. Users will find ways to interact with your app that you never even dreamt of- this is good and right, in my opinion, as long as it’s safe and respectful (and legal), but it does make design tricky.
Here are two great threads, one from reddit and one from stack overflow, for further reading:
When should I start testing?
In short, as soon as possible. Developers who said that their teams used a ‘build tests later’ approach sincerely regretted it because going back to write tests for code you may have written days or weeks ago is difficult. It’s easiest to write tests as you write the code the tests are for, according to several of the articles I read.
Like this ARTICLE
How do I make this thing as efficient as possible?
In order to answer this question, you should ask yourself two others: What will my app do? And perhaps more importantly: what will it NOT do? It is incredibly important to not overreach in the design phase of your app. Yes, go ahead and dream big, make your app the best thing ever, but then plan it and pare it down, then pare it down again. Kill your darlings, break it down to its absolute essentials. Make it so that your app does one thing great, not two or three things in a confusing, poorly designed way.
I have to come clean, I saved the best for last. Here’s a great guide to help you design your next app: THOUGHBOT’s GUIDE
This is thoughtbot’s playbook on how they make stuff, from the first post-it sketch to when the first user interacts with the finished product. There doesn’t seem to be anything else quite like it out there on the internet. It is incredibly thorough, informative and inspirational, and I suggest you take the time to read through every part of it.
Thanks for taking the time to read through this article, hopefully it gave you a decent idea of where to start when designing your next big project. As always, I’ll update this article if I come across any new and exciting info.