[rspec-users] RSpec makes me want to write better code

David Chelimsky dchelimsky at gmail.com
Fri Sep 26 20:07:39 EDT 2008

On Fri, Sep 26, 2008 at 6:47 PM, Mark Wilden <mark at mwilden.com> wrote:
> On Fri, Sep 26, 2008 at 4:16 PM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>> DataMapper, for example, offers auto-migrations. You just add a
>> property to your model file and it takes care of the migration for
>> you.
> The relationship between schema and models in Rails is weird. The basic
> source of truth for a model's attributes is the database. But the database
> is defined in Ruby. I don't know DataMapper, but it sounds as if it puts the
> responsibility in one place - the Ruby code.

A little rails history:

Before migrations data was defined only in sql. The argument for this
was that it was DRY to only define the data in one place. The result
was myriad comments in everybody's model files duplicating the schema
because they didn't want to have to look in two places to understand a

Enter migrations, which move data definitions to Ruby. Yay! Their in
Ruby. Except now they are STILL in another place :)

Now putting the attributes in the model as DataMapper and Og do comes
with its own problems. AFAIK, deploys for either require migrations
developed in sql. Nothing for free :)

>> If you don't need it now, or can't even justify the need for it in the
>> future, then it doesn't belong in the code OR in the data.
> So you would not collect fax numbers in this scenario. That's fine, but if
> you do need them later, you're completely, absolutely, 100% screwed. Kent's
> white book relied on the assumption that change is possible. But data
> collection is an area where change is not possible, so I don't think agile
> principles apply to it (necessarily).
> You might well ask, "how far do you go in collecting currently useless
> data?" And that would be a good question. :) I would answer that it would
> have to be decided by experience in dealing with business requirements, but
> not completely by whether there is a current need for it.

Again - "If you don't need it now, or can't even justify the need for
it in the future." If a customer wants it, then they should be able to
tell you why. If they can't and they still want it, then you might
have to give it to them if you want to get paid, but the conversation
is important.

Conversely, if you "know" from experience that the customer is going
to need it, then you should be able to rationalize that for them in
terms of business value.

>> If somebody
>> thinks "we might need it later" then it should be discussed as a
>> requirement and either introduced as one or dropped. If "we might need
>> it later" then probably somebody has a good argument why.
> Even with a good argument, "we might need it later" is unYAGNIsh.

YAGNI is a guideline, not a law. In practice, it doesn't mean "don't
ever do stuff you don't need right now" - it means anything being
imposed right now that isn't needed right now imposes a risk that it
will never be used, and the costs of that risk should be considered
when making the decision include or exclude a given feature or, in the
context of our discussion, data field.

If that cost is understood and a decision is made to include a
feature/data field anyhow because the perceived benefits outweigh the
perceived costs, then so be it.

>> If nobody
>> can think of a good reason, then why add the extra weight to the db
>> AND to the examples.
> Again, because you've only got one chance to get that data.

Ah, I misunderstood that you were talking about data *collection*. I
agree that data collection brings up a lot of different questions, but
I still believe that any fields that we're adding now that we don't
have a need for now should only be added after first seriously
exploring what the need might be and with a clear understanding of the
maintenance costs. Not to mention the impact on users who might
divulge information. If you can't rationalize why you need my fax
number, why in hell would I supply it? And if you ask me for 10 things
you don't really need, my interest in filling out the form decreases.

>> there should be a huge red flag and serious
>> discussion about why requirements are being imposed on a system for
>> which nobody can argue business value.
> Agreed, absolutely.

Thank god we agree!

Seriously - thanks for the convo. This is good stuff.


> ///ark

More information about the rspec-users mailing list