You’ve just typed rails new on your next project. Now what? Where do you start? Do you write everything in a single app, or go with a Service Oriented Architecture? Is this a good time to learn RSpec? Should you start building out all of your data models, or get a few actions working end-to-end? There are tons of decisions you have to make up front, and it’s easy to feel lost, and procrastinate, and get frustrated, and never finish your app.
This problem is super common. It comes from having to make too many choices up front, when you have the least amount of information you need to make an educated decision.
Convention Over Decision-making
Convention over Configuration is my favorite Rails principle. Before Rails, I’d get stuck figuring out where to put files, what to name database tables, how to map them to objects, and tons of other minor meaningless decisions. I’d spend more time choosing a direction than it would have taken to change my mind if I discovered later on that I was wrong.
Lots of the decisions you face when starting a new project will be like these. But you can replace these decisions if you borrow conventions from books, blogs, or styleguides. And you’ll save yourself a lot of time, stress, and meaningless debate.
Here are some conventions I follow when I start a new app:
-
Start with a few full features.
Your app doesn’t have to do everything you can think of right away. Start small, and start simple. Figure out the one or two features you can’t live without, and focus all your attention on those first. Build them really well. You can add other things later if you need it. But probably, YAGNI. (And you’ll usually find that what you think you need is totally different than what your customers think you need).
-
Start with a single app.
I know, you want to avoid building a Monorail. And there are a half dozen RailsConf talks about how SOA is the best way to keep Rails apps maintainable in the long term. Shouldn’t you figure out which parts of your app can be independent, and build a service for each part?
SOA is a great way to break apart a large, complex app. But it adds a ton of pain, and unless the pain of building, maintaining, and monitoring services outweighs the pain of working on your monolithic Rails app, it’s not worth doing. And if you haven’t started writing your app yet, you’re not feeling that pain. So, start with one app.
-
Start with a stack you’ve used before.
If you don’t know a stack yet, just use the Omakase stack. But either way, you don’t want to spend half a day integrating a test framework you’ve never used before with Rails. You don’t want to fight version conflicts between VCR and WebMock. You don’t want to have to figure out if your tests crashing is your fault or resque_unit’s. If you want to try a new library out, you can always add it later (or try it on a toy project).
Shipping is hard. If you want to finish your app, you have to scrape for every advantage you can get. So start small, start simple, and start with what you know.
Conventions may not always be perfect, but they’ll help you get started. And starting is the hardest part.
What’s next?
What conventions do you follow on your projects? And how do you decide which features or tests you should start with? I’ll share my thoughts next time, but I’d love to hear some of yours.