This Is Not a Rails Shop. Chad Fowler, VP Living Social.

How to build a system, a team, and a professional practice that can survive.

“Morked”. Used to describe Visual Basic developers who are given tools to use (and training sometimes). They get dragged along by a company and are told what to use and how to use it.

You can get used to building defense systems, personal immune systems against the Mork mindset.

If you’re doing something right, the Morks are usually doing something wrong. But you can get blinders put on by doing this all the time. ”DHH is a charismatic leader who can effectively rally the troops.” Left unexamined, binding your opinions to those of a leader can become like a religion.

Rails is not a work queue. Not a messaging queue. Not an event processing engine. Not an analytics engine. Not a service bus. Use Rails for its strengths and use other technologies where needed. Very few apps are just MVC web apps, so very few web apps should be just Rails.

(Note: I don’t think DHH would suggest Rails is any of those things, so not sure why Chad is tying these two points together.)

Rails does scale. Using MVC architecture to solve problems that it wasn’t meant to solve does not scale. Rails scales when you use way more than just Rails.

Avoiding SQL at all costs typically sets a “Rails Mork” aside from someone who uses Rails to deliver a front end.

The Big Rewrite blog series by Chad Fowler

Don’t be afraid to throw away your architecture if it is not the right fit.

Another definition of legacy is “gift”. Do we ever think of our legacy software that way? Can we write our legacy software in such a way that it can be a gift for others to work with in the future?

Nobody will remember your work when you die. Statistically speaking, we’re all just going to create some transient crap that will be replaced.

Working Effectively With Legacy Code by Michael Feathers

Characteristics of Legacy Code: Fear, Stasis, Difficult to Change

Your Code.. It’s Alive.. by Michael Feathers

Design Beyond Human Abilities by Richard P. Gabriel

How do we create software systems that outlive us? Why can we, as complex systems, survive but our software cannot?

Our body relies on homeostasis, the ability to regulate itself, in order to stay alive. An inability to maintain homeostasis may lead to death or a disease known as homeostatic imbalance.

You are dying right now. There are 50 trillion cells in your body, 3 million die per second. We are completely different cells from what we used to be. Maybe this is the key to surviving systems. Systems that survive are made of tiny cells that can be replaced frequently and easily.

What is a cell in software development? What is a system? When do you build a system vs building a cell? Are you building the right one now?

Killing and replacing cells regularly forces you to work with small components. Homeostasis requires killing and replacing cells frequently. Keep components small and kill and replace often for healthy systems.

If something is hard, do it all the time. What if we did that with rewrites? What if we did rewrites all the time?

Force heterogeneity. Have simple interfaces.

Hire the best programers, not the best ruby programmers.

Books to read:

Get a strong grasp on HTTP:

  • Read a web server’s source (try Unicorn)
  • Write a simple web server.
  • Read and memorize all HTTP status codes.
  • Deeply understand and implement HTTP caching.

Full video from talk available fromĀ Chariot Solutions.