What almost a decade of development in Ruby on Rails taught me about quick prototyping
Millions of mobile and web applications are created every year, with only a small percentage of them ultimately succeeding. Quick prototyping is more crucial than ever, not only for creating new services but also for deciding which directions to follow in future product development.
Prototyping an application: the importance of the planning phase
We've all had an idea for "Facebook, but for cats" or "a better messaging app." Although thinking big is usually good, it certainly doesn't inspire confidence in developers who know exactly how much work is required to launch even a small-scale application. As a developer with almost a decade of experience, I've listened to hundreds of ideas for new products. The majority of them took the form of a massive scope of functionalities.
The planning phase is an essential step to plan product development successfully. In principle, it should answer a simple question: what problem should the product solve and… how to get rid of everything else (at least for the initial product). Planning is the only way to make sure that developers spend most of their time working on the app’s core features.
From a developer's point of view, most of the applications aren't that unique. Going back to the infamous "Facebook for cats", the underlying structure of the original Facebook would have to remain the same, with just a fraction of the app customized to be able to handle cats and their unpredictable nature.
Prototyping with Ruby on Rails: better fast than perfect
Installing Ruby on Rails is a good idea for building a proof of concept. It will get you a handful of generators that can set up the core structure of the application. The creation of models, simple views, and controllers can be done with one command:
rails g scaffold books title:string author:string isbn:string
After just a few minutes, you will have a working application that allows you to store books with some details. Adding users to the mix is even simpler: all you need is a new table in the database and some controllers to handle creating and updating:
rails generate model user name:string rails generate controller users
It's the most simple example, but it's just the tip of the iceberg. Functionalities that are prepared following DRY (Don't Repeat Yourself) are visible everywhere in Rails. To name but a few:
ActiveRecord: It provides an Object-Relational Mapping (ORM) database, associations between models, validations of data, and migrations. The developer no longer has to touch the database itself. An additional level on top of the database also allows you to easily switch between, for example, PostgreSQL and MySQL, as ORM already knows how to handle them.
Strong parameters: It allows for the filtering of the parameters not prohibited from being processed in the controllers. If you take, for instance, a long list of attributes from URLs, this radically increases the security and helps to define which are the fields intended to work with the rest of the application.
Partials, Helpers, Forms: Standard elements of each modern application, neatly included in Ruby on Rails to organize code better, and to prepare used parts very quickly.
A very mature framework like Ruby on Rails also provides a lot of plugins called gems. To not repeat standard functionalities, there are modules available for user authentication, payment systems, or connections to external APIs.
The mentioned features are not perfect; neither are they meant to be. Instead of aiming for perfection, a better idea was to make them as reusable as possible, existing as building blocks that only require a proper connection.
Quick vs. custom prototyping
The pros of custom prototyping
It doesn't require a lot of experience as a developer to say that it's a good idea to use as many already developed plugins and elements. It speeds up the process of setting up a basic application and makes things easier for beginners. However, more experienced developers can prepare the same structure from scratch and write everything down in just about the same amount of time.
The question is: if the things that can be done almost automatically aren't that hard to do manually in the first place (provided you're familiar with the framework), why not do it? It can save you from having to solve time-consuming issues down the line.
The cons of using gems and packages
Using gems and packages also has its downside, though not immediately obvious. Let's take a payment system, for example, that provides gems for Ruby on Rails to implement basic payments quickly. In most cases, it saves some time and often doesn't even require an understanding of the underlying logic as it varies from one provider to another. The problem starts when some of the needed features for the payment system aren't part of the plugin included in the application.
If a payment form that was generated by a handy one-liner now needs to collect some additional data or behave in some custom way, the real hacking needs to start. Instead of merely understanding the payment system endpoints and connecting to them, the developer now has to figure out how the external gem works and how to extend only some of its parts without breaking others.
It was just one example, but I think the tradeoff is clear. It's possible to prototype using external plugins or whole platforms like Spree, but when more custom features are required, we are rapidly losing the advantages of doing so. External code imported and "hidden" in gems’ logic can, in many cases, actually slow down development.
To sum it up, only develop what's unique
The planning phase is crucial as nothing optimizes a developer's time as much as removing the features that are not important. With new products, it's often hard to guess what is unnecessary. That's where quick prototyping comes in. Quickly going through multiple iterations of a product is nothing new, but it's even more critical in the landscape of millions of apps trying to win users' attention. It reduces the risk of spending too much focus and resources on service parts that may end up being removed.
This is where Ruby on Rails’ features combined with external plugins come in handy. Modern frameworks can be very useful for fine-tuning business models during the development phase as they allow the implementation of new features (without too many customizations) for testing users' responses. In turn, It leaves more time to focus on building a unique code. And this is what developers enjoy best.
Do you want to know more about how we develop apps? We’re just a message away! Or drop us a line at firstname.lastname@example.org
You may also like...
Congratulations, you’ve just come up with an awesome startup idea that’s going to change the world! And afte...