Building an in-house team can be quite a challenge. That’s why remote development teams are gaining popularity, and more companies use services of Ruby on Rails development agencies. It’s an attractive alternative, but if you want everything to go smoothly, make sure that you prepare yourself before you start cooperation. Communication and transparency are crucial in Ruby on Rails development. Following certain rules will help you solve all potential problems, manage workflow, and keep all issues under control. Before the setup, you should learn a little bit about the technology so that you can understand your team better and streamline the process.
The client: the most important part of the process
The cooperation between a client, and a development company is both very individual and generic at the same time. From the development’s team point of view, the goal of the cooperation is to create a product and possibly maintain it in the future. That’s why wrong assumptions, approach, plan, and the execution of that plan can lead to different expectations and results at many stages of product’s creation.
Rule #1: Find time to meet with the team
The client will have a very specific vision for the product. But very often, the client forgets to communicate that to the Ruby on Rails company. So the first thing you should bare in mind is to make time in their calendar for regular meetings with the development team. Meetings should take place at least once a week, for a number of reasons.
Meetings constitute a good opportunity to present the progress with the product made by the development team in each sprint. From my experience, during meetings, clients will have many questions about developers’ work, in accordance with the workflow, layout, and business logic. At such meetings, called stand-up meetings, many edge cases are very often targeted and clarified. A stand-up meeting should take place at least once a week, but twice would be even more beneficial.
You can be sure that the project goes in line with assumptions and the timeline. That argument is very valid in terms of time and budget.
Frequent meetings adhere to the lean management approach to creating web products. This approach guarantees delivering more value with less waste in the context of a project.
The final product can differ very significantly from the client’s first idea. This is why the development agency should cooperate closely with the client in order to react to any changes and requests to make sure everyone is on the same page.
Rule #2: Get acquainted with the tools and crucial project details
In Netguru, we believe that transparency pays off. It enhances the development, it improves relationships in the team, and it also increases the quality of the work with the client. That’s why you should be familiar with all the vital information we provide. You should have full access to the:
tickets in project management tools
documents such as readmes, plans, and mockups.
Transparency requires security, so all data is provided in a secure way. For instance, we use 1password to handle passwords, addresses, and confidential data.
Rule #3: Be present
The process of creating a web application presents multiple challenges, variables, and edge-cases that will occur during cooperation with development agency. Such complex eco-system requires being present in many ways.
Use staging and beta servers after the development team finishes work on new functionalities. It is very important because the faster you test functionalities, the faster you can spot the discrepancies between the client’s vision.
Slack is a great communication tool. You can ask questions on dedicated Slack channels, so the developer that created functionality or PM can respond.
In Netguru, we use JIRA. We think it is one of the best tools to track project progress. We know that not everyone has the habit of working with a tool of this kind, but try to make an effort to use JIRA.
Rule #4: Try to understand the development process and the RoR ecosystem
Ruby on Rails (abbreviated as RoR) is a popular web framework for web application development built in the Ruby programming language. As a full-fledged web framework, RoR offers many components of a successful web project out of the box, for instance, an ORM (Object Relational Mapping) system for business data and logic, routing, and application management. Still, to decide whether RoR will be a good fit for a specific project, you need to know what makes this framework different from others. To help you get a deeper understanding of RoR, we will give an overview of its main strengths and its shortcomings.
The best industry standards. RoR has had over 13 years of constant development. The fundamental principles that RoR has been built upon made it highly regarded in comparison to other frameworks:
The DRY (Don’t Repeat Yourself) is a principle in software development aimed at reducing repetition of all kinds. It ensures a clear separation of concerns and maintainability of your application.
The MVC (Model-View-Controller) is a software architectural pattern for implementing user interfaces on computers. It divides a given application into three interconnected parts. It is a core feature of Rails and makes it easy to work with RoR and solves multiple problems such as how to include new features and where to place the appropriate business logic.
The speed of development. The main goal of RoR is the speed of development, especially in the prototyping phase. Most web frameworks were not created with the aim of fast prototyping. Rails, on the other hand, is perfect for developing prototypes quickly. You can easily integrate all major databases (both relational and non-relational), use authentication and authorisation layers, integrate with cloud storage services (Amazon), and many more. All libraries can be found on GitHub.
The community. RoR is open-source, so any developer in the world can report an issue, solve one, or contribute to the growth and evolution of not only the framework itself but any open-source library being part of RoR. The open-source nature of RoR results in top-notch security standards, which are monitored and kept up-to-date with the industry’s best practices.
Still, Ruby on Rails also falls behind the competition in a few respects:
‘slow’ runtime speed,
potential issues with multithreading and the processing of simultaneous requests.
Bear in mind, however, that the impact of all the above issues can be significantly mitigated by a proper design of the application’s architecture.
The effective collaboration checklist
When working with a RoR development company, you have to manage the work with people, not only with software. Agencies understand that their client’s success is their success too and will do everything they can to make this success a reality. In order to work efficiently with an agency you should adhere to a few principles and everyone will be happier.
Rule #5: Prepare yourself for the cooperation
Before the collaboration starts, you should do a few things to make everyone work more efficiently.
Check whether the company is responsive to the business and marketing changes suggested by the client.
Check the internal procedures of the agency you’re about to choose.
Check whether the agency has a talent team responsible for delegating the right people to the right job.
Talk with other clients of the agency you’ve chosen and ask about their experience.
When you start the collaboration:
Prepare and provide access to repositories, mockup and graphic designs.
Put together a list of ideas and user stories.
Write down the questions about your project as a list.
Describe the market and identify your target group.
During the co-operation, you need to:
Specify the requirements for your MVP.
Set up all the necessary communication channels.
Always ask questions when you don’t understand something.
Identify the next steps to be taken.
After the launch of the product or at the end of the collaboration:
Make sure you keep the agency close to hand.
Check whether the code you’ve been given is well-documented.
Ask about maintenance services for your product.
The best practices in Ruby on Rails ecosystem
Every ecosystem follows a set of guidelines. You should know them in order to maximise the gains from collaborating with an agency. In the case of RoR, the guidelines are as follows.
Use gems. Gems are open-source libraries which you can reuse them in many projects. If you need to implement user registration, image uploads, or automatic e-mail distribution in your application, feel free to use an open-source library. You don’t need to write it from scratch.
Use the right database for your use case. Choose the type of a database appropriate for your problem wisely. You can choose relational databases (RDBMS) such as MySQL, PostgreSQL, MariaDB, Percona, and many more. On the other hand, also non-relational databases are available: MongoDB, Redis, Cassandra, CouchDB, and others. A database you would use for storing users in the system would differ from a database used for real-time storing and processing chat messages for millions of users. Every database was designed with a particular purpose in mind.
Consider using an external API. Your development team doesn’t need to write everything from scratch. They can use an external API to save time and money so that they can focus on solving other, more pressing, issues. You don’t need to write software for converting currencies, posting messages on Facebook, or using Google Maps. All major companies in the world have an API available that you can use for a small fee or free of charge.
Follow the best RoR and programming patterns to keep your software maintainable and easy to develop. The acronyms DRY, KISS, and SOLID should be no mystery to you. Use the right design patterns, keep your software and libraries up-to-date, use useful database features such as indexes, views, Postgis, or full-text search if needed.
Use continuous delivery tools. In order to save time on delivery process. use tools that make this process as painless and automatic as possible.
Ready to Start Yet?
Even though working with a remote team might have its downsides in comparison to an in-house development team, with the right preparation and management, you won’t feel the difference. The crucial principle to follow is to treat all the members as if they were employees of your own company. They need to understand your vision in order to follow and execute it.
If you want to learn more about working with remote teams or you’re ready to hire one, drop us a line. We’re here for you!