You ain't gonna need what?

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).

tags: , , , ,
  • It’s time to bring software engineering back into the conversation.”

    When was it time to take that out of the conversation? I mean, I know it happened when there were some products people wanted to promote but was that really a good time to take engineering out of the conversation? And, how is it now time to reintroduce the topic of engineering, is there some product to… oh, I see.

    Also, which events around Rails constitutes a “movement”?

    Finally, why is what is “designing for failure” in one paragraph described as “fine” in another? Is it ever fine? (“Try not to screw the customer too badly.” – Sussman and Ableson)


  • “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.””

    Yeah, sure. That sounds like a good idea. Tell the customer to go away. After all, some geek in a cube coding away obviously knows what the sales team does or doesn’t need. I think it’s time to start really listening to customers instead of coding in the great ivory tower.

  • Mike

    @Mike DiPetrillo

    I think the largest problem in the industry is exactly the opposite. Increasingly over the last decade I’ve seen more and more people in our industry doing anything and everything the user asks, even when it is unethical, even in medical research. Users increasingly are no longer asking for our professional opinions, but telling us every technical aspect of how we should do our jobs.

    I’m amazed and deeply troubled by the number of “professionals” in our industry that have either never learned or abandoned all professional ethics and responsibility, and simply do whatever the user says, the way the user says to do it. Would you really want to go to a physician, lawyer, or other professional that would just do whatever you say?

    After all, if the guy in the cubicle is really so deaf to the needs of his users then this users get exactly what they deserve if they keep paying him.

  • And as Twitter has shown you don’t need scalability, good data or extendability either. It has been painful for them but they are still here and growing.

  • @Mike (the other Mike)

    I’m not saying to just put in whatever the customer is asking for and have it break compliance or ethical constraints. However, as being someone that works at a large software company and is on the customer focused side of that company I can give you many times where customers have asked for really useful stuff that didn’t break any laws and engineering pushes back and says that customers would never use that. All I’m saying is it would be nice instead of just saying no to really try and understand why a customer is asking for the feature in the first place. I think we can all agree on that but it wasn’t the message delivered in this post and it’s something a lot of developers need to take time to learn to do.

  • Thomas Lord +1.

    The tragedy of Rails is its enshrinement of a reactionary, conservative, isolated design & development approach. It’s not fully accurate to say that Rails has been “willing” to throw out rules – Rails makes it an article of faith to throw out those rules: programmers: you ain’t gonna need it, designers: meetings are a waste of time. To my ears, it carries just about the same moral tone as Mike Muir’s rant from Institutionalized – “all I wanted was a Pepsi, and she wouldn’t give it to me!” Awesome song, not necessarily an approach to work by.

    The time to introduce engineering is when engineering becomes necessary. That will be different for every project – Twitter’s been hacking away at it for years, but my little app in the corner may never need it.

  • Rails certainly has some incredible benefits when it comes to creating new apps… the big question to me is still the reliability and security over the long haul in a production environment.

  • “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”

    What you just described is Agile project development instead of waterfall, it has nothing to do with Rails.

    Also telling a customer YAGNI isn’t constructive. What you need to do is understand why they think they need it, and get them to think about how important that feature is compared to the other things they want, and if they’re willing to push another feature out to have the new one in. If they aren’t, then it’s not that important, and you can try to convince them that YAGNI.

  • W.r.t. YAGNI, remember the value of Respect, and the power of Five Whys.

    Your customer isn’t a retard; if he comes to you with a feature request, it’s because he wants the software to solve a problem he has, even if he doesn’t know the best way of solving it.

    So firstly, remember the value of Respect: respect your customer & the input he is giving you, and treat it as a useful source of knowledge.

    Then resolve it using the Five Whys.

    It might be that after more detailed analysis, you realise that the problem being solved by the feature is reasonably minor, and can be punted. In this case you’re effectively saying YAGNI, but only _after_ some detailed investigation and discussion.

    Or, you might realise that the root cause is an extremely important scenario (perhaps _more_ important than the customer at first required) and that the feature should be prioritised.

    But if you just reply YAGNI up front, then you’re disrespecting your customer, jeopardising your product, and missing the point of Agile development entirely.

    W.r.t. scalability from the ground up, the assertion that “all software projects [are] gonna need … scalability” is trivially disprovable.

    Rails is making more and more headway into organisations as a means of quickly and reliably producing ad-hoc solutions to internal problems; there is simply no way that “scales to millions of users” will ever be a useful feature for a product intended to share data between, say, three researchers on an R&D team.

    W.r.t. data integrity and extensibility, I agree wholeheartedly.

    Data integrity is just vital (& it’s somewhat shocking that Rails has had poor support for DB-enforced integrity in the past). I’ve worked on a project for a major insurance provider where the working dataset was corrupt in _so_ many different ways … it was an absolute nightmare when compared with other projects that had a reasonable degree of data integrity.

    The thing about extensibility is that good architecture (separation of concerns, domain driven design, DRY, etc.) should lead naturally to code that is extensible.

    The Five Whys help here: if people are raising extensibility difficulties at retros, examine the reasons in detail. Painful extensibility is a great predictor of deep underlying problems.

  • Phlip

    This Rails bashing sounds like XP bashing back in the day.


    > Rails invented XP

    > XP is just a watered-down Agile

    > All Rails programmers never collaborate,
    go to meetings, write unit tests, deploy
    daily, or refactor their code

    And the most important point:

    > All Rails programmers swear an oath to forget
    everything they learned about robust design.

    The Ministry of Propaganda now returns you to your regularly scheduled disinformation.