Why Is Choosing Good Solutions for Projects So Hard in Rails?

For a long time, I’ve been hearing a lot of criticism about the Rails way and some months ago my private experiences convinced me that I cannot find any use cases for that approach. It has developers build very fat models, controllers, and DRY is commonly understood as a method of extracting repeated one-liners to new methods.

What happens to every OOP principle in said approach? Does it allow applications to be easily expanded or refactored? Nope—because an app written according to the Rails way should be saved in the archive of antipatterns.

Am I exaggerating? Well, maybe a little. Naturally, we know what the industry is like—we’re often facing a situation that has us running with our ideas as soon as possible and treating code quality and complexity of architecture as side issues, really.

When the most important aspect of our business idea is the very brief implementation timeline, we need to remember that our technological debt will only keep increasing. If we manage to keep that in mind, all will be well—problems arise when we decide to develop our application further without ever reflecting over our codebase. 

A few months ago, after a great discussion with my colleague, Jan Dudulski, I seemed to have grasped one very nonintuitive thing—namely that the Rails way has a couple of productive, useful aspects.

Naturally, no one interested in developing serious applications should concentrate on this particular approach, but it’s perfect for blogs, very basic APIs, and prototyping. If we have a few days to create a basic functional structure to check whether an idea for an app makes sense, it seems to be the best available solution.

We must bear in mind, however, that everything depends on the individual case. Something that once was a very basic API may quickly balloon to monster size. Therefore a prototype quickly matures into the final version. On the other hand, however, I know cases where the plans were great, we implemented hexagonal architecture, repository patterns, DDD, but it later turned out that we’ve spent 75% of our implementation time on creating the architecture.

There are no perfect recipes for developing applications, but in my personal opinion, every developer should practice what I call “an examination of conscience.”

Such a recap tells you three things:

1. What do you know?
2. What is possible?
3. What isn’t possible?

Should the need arise, you could do a “test drive” or “spike” using some preferred approach. Try a naive implementation of a characteristic, a hard functionality, but don’t spend too much time on the effort.

Such an exercise will push the envelope of your personal development further than reading ten great essays, but, more importantly, it will give you a better understanding of the pros and cons of a number of solutions and patterns. 

Why is that so important, you ask? Well, because each case, each client, and each project are completely different. What’s worse, ten developers are easily capable of coming up with a dozen or more different solutions to the same problem, therefore, the more “active” research you do (by that I mean testing solutions, rather than reading about them), the more you will be able to infer from looking at the same specification again. 

What’s the most important thing, then? Well, many of us tend to think: “If I didn’t write the production code and it’s worse than my original idea, then my work is completely useless.” You couldn’t be further from the truth on that one! I’d venture to say that each line of code we write opens our minds to new approaches and solutions.

We need to remember that probably every single thing we learn will ultimately be useful for us in the future, somewhere down the road.