One of the defining characteristics of the Rails movement has been its willingness to throw out the rules by which software developers and consultants have typically worked. Those rules typically produce big, overblown projects laden with features that no one ever uses–but which sounded good during the project specification phase. Build the simplest thing that could possibly work, and add features from there; say “You ain’t gonna need it” when partway into the project, stakeholders come along with strange requirements based on what they think they might want.
This is fine, and has enabled Rails developers to deliver working
applications quickly. But there’s also been an overreaction.
What are all software projects gonna need?
- Data integrity. There’s not an application in the world that works
with corrupted data. The good news is that corrupt data is avoidable. - Scalability, the ability to support more users. While you wouldn’t
start off building your project to support millions of users, you
also don’t want your project to die as your user base grows. I don’t
think anyone’s out there saying “Hey, I’m glad we didn’t waste time
making that app scalable, because no one wanted it anyway.” And as
@al3x of Twitter said recently, “thousands of anything is not a
whole lot.” - Extendability, the ability to incorporate new features. While you
don’t want to abandon the YAGNI battle cry, you know that you’re
going to need to add features. A well-thought-out design makes that
easier. The Portland Design Wiki has the best statement of
the YAGNI principle–but it also says “This doesn’t mean you should
avoid building flexibility into your code.”
If you’re not designing for reliability, scalability, and
extendability, you’re designing for failure. One of the
reasons I
like Dan Chak’s Enterprise Rails so much is that it’s about how to
design for success. As Dan says, “these topics are universal, and
Rails does not give you license to do an end run around good
architecture.” It’s time to bring software engineering back into the conversation.
When the head of sales comes into your office and
tells you that sales reps need to be able to look up the complete
sales and credit history of any customer in the field, you can tell
him “you ain’t gonna need it.” But you will need to extend that
application, you will need to support more users, and you’d better
make sure that your data stays coherent. Laziness might be a virtue,
but if all you’re interested in is saving work, and not building
something that is capable of succeeding–there are even more radical
ways of doing less. exit(1).