Article  |  Project Management

What the BLEEP is Ruby on Rails? A Project Manager's Perspective

Reading time: ~ 3 minutes

What the BLEEP is Ruby on Rails? A Project Manager's Perspective

As a project manager, it helps to understand all the details of a project (wink). Sometimes, though, while juggling several schedules, milestones to hit, requirement scope, budgets and a multi-disciplinary project (of which you are not even close to an expert in any discipline), knowing most of the details is usually enough. Knowing the user stories being explored by the interaction designer is important. Knowing that the visual design is in line with the style guides for the brand you are working with is a big checkbox to check. Knowing and outlining the functions the users will be able to perform thanks to the backend code is definitely a requirement. However, knowing the backend code language and what the platform it’s running on and how they work together to deliver you a stable and high-functioning application? As we sometimes have to say on the job, is a "a nice to have."

At Planet Argon, we build web applications primarily with Ruby on Rails. We’ve built them from scratch and we’ve inherited and worked on existing Rails applications. When I started as a project manager here, I knew basically what that was and meant: that it was a language (Ruby) that powers a framework (Rails). Leaving it there would probably be OK. But oh, what the vast knowledge and confidence you would be missing out on if you stopped there.

Ruby is so much more than a language, it’s a whole community. Its rules and protocols are built on the conversation and general agreements of a democratic pool of people. Changes to the framework are made by a formal team. But in addition to that team is a massive pool of contributors; people who are not only formally recognized, but people who document, write blogs, and simply express interest in the evolution of the framework. There is a specific code of conduct in code writing, so to speak, that has been agreed upon as the standard. Things like writing comments within the code, creating tests that give code bases fortitude and other expectations that allow Ruby developers to easily pass information back and forth to each other, even if they don’t work together or have never spoken.

That’s an important distinction to make. When there is a clearly defined expectation, you can make headway on an existing project much quicker. You can also let you clients know how effed/un-effed their project is pretty quickly. At Planet Argon, we provide Code Audits for new and prospective clients. At the minimum, if we can’t run down a list of checkboxes after reviewing your code, you know quickly how well your Ruby on Rails project was handled.

The philosophies of Ruby on Rails helps propel this community forward too. For example, a Ruby code base should only need to identify the unconventional aspects of the code. The assumption being that all other parts fall under the conventions of the Ruby community. If there are no comments, you can assume it’s just doing the thing it’s meant to do in the code base. Seems like a simple and obvious way of doing it, right? Think of it this way: take the number of developers in the world, multiply it by 3 and that’s what I would guess to be the number of different ways an application could be written to reach the same functional end. For those not confident in math, I mean to say, that’s a lot. And that could be a recipe for a cluster of a code base. But with Ruby, conventions are king, and if for some reason it isn’t, that’s the only reason a comment might be present. This paves the way for clean, understandable, consistently written code base, across projects, agencies, and developers. Which means a smoother ride for your users (and your feature updates).

This is one of the most important aspects of Ruby that I have learned. A developer that builds an application within the constructs of the Ruby community should be able to effectively pass that code base to another developer with little to no communication. The way the code is written should speak for itself. Plain and simple.

As a project manager, everything that Ruby on Rails has to offer can amount to happy developers that are provided with a quick and direct framework and process to write code and get features into place on web applications. It provides a community for asking and answering questions and provides an open source for many of libraries that make the development of a feature quicker than needing to write it from scratch and cheaper than buying one for any isolated purpose.

Ruby on Rails doesn’t make project management a breeze, but it can certainly provide a stable starting point, wherever your project begins.

Have a project that needs help?