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.
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.
When you realize that you're no longer in control, you:
Here's a classical list of the things learned (or learned more deeply) at this stage:
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:
You get control, but you lose any sense of joy when you're writing such code.
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.
Not much actually:
In other words, we want painless Rails without overengineering. If you're looking for that, congrats, you're in the right place!
Go straight to the Painless Rails approach, or learn more: