Why did Rails become so popular, so quickly?

The simplicity helped, especially if you came from the Java, XML, Enterprise world. It was also marketed incredibly well. But that’s not everything.

A lot of Rails’ success in the startup world came from a simple fact: The problems businesses have aren’t that unique. Rails was great at creating CRUD sites, while remaining flexible. And that’s really all a ton of businesses need. Especially at the beginning.

But this isn’t just true for businesses. A lot of the problems we face as software developers don’t change. Sure, our solutions evolve. They cycle. We get better. But the same solutions discovered by the last generation of developers can still help us today.

So, do you want to know the answers to the problems you’ll face in the future? The best thing you can do is look to the past.

Look to the past

On his website, Martin Fowler has an unbelievable collection of good solutions to common problems. Have you been hearing devs talk about Event Sourcing? He wrote the definitive article on it 10 years ago. Chasing performance and reliability problems with your new REST API or Service-Oriented Architecture? It’s his first law of distributed objects, from close to 15 years ago.

Avdi Grimm told me that “If you want to lead the technology curve, start investigating whatever Martin Fowler was writing about a decade ago.” That’s totally true. The time you spend reading through the patterns on his website will be a great investment in your programming future. And that’s not even mentioning the refactoring patterns.

Going further, just about any book or article written by the authors of the Agile Manifesto is worth reading – 15 years ago, they were working through the same software architecture problems we run into today.

You can find a lot of their discussions on the C2 Wiki. The debates we have about when TDD makes the most sense? They’re all there. And they’ve been there. The wiki has been around for a while, and it’s still a fantastic resource.

Books from the late 90’s to the early 2000’s are also helpful. I smiled all the way through Smalltalk Best Practice Patterns and Patterns of Enterprise Application Architecture (which was a huge influence on Rails), because they described problems I’ve had so well.

Just like design fashions, software development practices cycle. From distributed to centralized, from client side to server side, from dynamic to static.

Do you want to get ahead, understand what’s coming, and maybe even drive what comes next? Look to the past. Research the solutions to the problems that our current solutions will cause. And help bring the good practices of the last generation of software developers to the next.

Did you like this post? You should read these:

Finished another Rails tutorial and still don’t know how to start?

Have you slogged through the same guide three times and still can't retain enough to write apps on your own?

In my free 7-part course, you’ll discover the fastest way to learn and remember new Rails ideas, so you can use them when you need them. And you'll learn to use what you already know to build your own Rails project.