At RubyConf last year, I announced a new book I was working on that outlines the way to write Ruby on Rails apps sustainably, so that teams, orgs, and code could continue to be valueable and easy to work with over time.
From the first chapter of the new book:
To sustain the development of our software is to ensure that it can continue to meet its needs. A sustainable web app can easily suffer new requirements, increased demand for its resources, and an increasing (or changing) team of developers to maintain it.
A system that is hard to change is hard to sustain. A system that can’t avail itself of the resources it needs to function is hard to sustain. A system that only some developers can work on is hard to sustain.
Thus, a sustainable application is one in which changes we make tomorrow are as easy as changes are today, for whatever the application might need to do and whoever might be tasked with working on it.
The book is more than halfway complete, and you can buy the beta version right now for $29.95. I’ll be updating it as frequently as possible.
This book is based mostly on my 6+ years at Stitch Fix helping to build and run the engineering team. We started with one Rails app and, when I left, had over 60 in production. I learned a lot about what does and does not help keep a team productive when working on a multi-year-old Rails app.
The biggest boon: don’t put any logic in your Active Records ever. An early chapter in the beta version explains why, and does so without appealing to morality, authority, or personal style.
The biggest thing that will kill your team’s productivity? I can’t choose one, but here are three that I saw in action turn a productive team into one that moved glacially: lack of a design system and CSS to support it, shitty dev environment, using the JAMStack when there was no technical or organizational need. These are all covered in the book.