Rails hurts developers :(

Maintaining big Rails apps is hard. Even small applications developed chaotically can cause problems. Let's have a deeper look into what causes those problems.

Some developers are getting cut by famous Rails sharp knives. Others are buried under piles of over-complicated code written to make them less dependent on Rails.

Both situations are bad. Let's examine them.

Lack of control

The first scenario: You rely on Rails instruments too much. You think that your back is covered, you control the situation. Clients are happy, you're happy!

But then your development speed starts to slow down. Simple tasks require more and more time. The quality of the produced code also goes down. You get more and more unexpected behavior of the system you've developed, so you spend more time supporting it rather than improving and developing new features.

You thought you have control over the system you've developed. You thought you're producing quality software, but at some point, you realize that it is no longer true.

This is a very painful moment. Not everyone has the courage to admit it. Some have to ruin multiple applications before they admit that their picture of the world needs adjustments.

This is the reason why so many people become disappointed in Rails.

Too much control

When you realize that you're no longer in control, you:

• become angry at the thing you relied before (Rails)
• invest your time in learning and trying approaches promising to return that control into your hands.

Here's a classical list of the things learned (or learned more deeply) at this stage:

• SOLID principles
• OOP
• Design Patterns
• TDD
• DDD
• Clean/Hexagonal architecture

These and many other things have become a pop-culture, and it is hard to miss them. Unfortunately, zeal without knowledge is a fire without light.

If you're work hard enough, you'll manage to get control back. The problem is that the cost might be too high:

• too much boilerplate code
• too much handworking
• fighting against Rails and its conventions.

You get control, but you lose any sense of joy when you're writing such code.

The hope is lost?

If you manage to get caught by both of the above traps, you can become really annoyed. Many people on that stage decide that they had enough of both Rails and Ruby, and decide to switch to other programming languages.

Ruby is designed for programmers' happiness and productivity, but when you get exactly the opposite, you become frustrated and disappointed.

What do we want?

Not much actually:

• our joy back
• to have control over the situation
• scalable complexity management system
• with least possible overhead

In other words, we want painless Rails without overengineering. If you're looking for that, congrats, you're in the right place!