Velocity, in the Agile sense of the word, is a measurement of the number of user stories completed in a period of time. I’m very new to the concept, but I’m immediately skeptical for the following reasons:

• Technical debt is nowhere represented in the velocity model. In fact, optimizing for short-term velocity will tend to accumulate technical debt. The incentive here is toward shortsighted implementations that will satisfy the acceptance criteria, with less care taken to accommodate future requirements.

• Because velocity can be so misleading, it is often abstracted away from stakeholders. The measurement also tends to be too technical to be exposed to corporate officers. Given that velocity will tend to be used internally within a development group, why not express more of the complexity and uncertainty of the development process?

Validating our Rails associations can be a balancing act. Insufficient validation can lead to garbage in the database. Overzealous validation can lead to needless complexity. Here are a few lessons I’ve learned:

• Validate presence_of where there is a belongs_to. Consider the crazy cat lady:

  class CrazyCatLady < ActiveRecord::Base
    has_many  :cats,
              inverse_of: :crazy_cat_lady
  end
  
  class Cat < ActiveRecord::Base
    belongs_to  :crazy_cat_lady,
                inverse_of: :cats
  end
  

  Should a cat exist independently of a crazy cat lady? Philosophical ramifications aside, we’ll say no. Since we only really care about tracking crazy cat ladies, the cats are only important inasmuch as they relate to their ladies. The belongs_to is a guide that we probably want to validate presence_of, like so:

  class CrazyCatLady < ActiveRecord::Base
    has_many  :cats,
              inverse_of: :crazy_cat_lady
  end
  
  class Cat < ActiveRecord::Base
    belongs_to  :crazy_cat_lady,
                inverse_of: :cats
  
    validates_presence_of :crazy_cat_lady
  end
  

  Why aren’t we also validating presence_of the foreign key (crazy_cat_lady_id)? We’ll see in a moment.

Some bad Git commits you can’t prevent. I’m talking about the ugly, last-minute implementations that pass the test suite but will give you nightmares for days. Or commits with nasty bugs that will only reveal themselves days later on a corner case.

Some bad commits, though, you absolutely can prevent. And there’s a way to automatically prevent them, every time you invoke git commit: Git hooks.

• Presence validation in the model without a schema constraint.
  Presence is one of the most common ActiveRecord validations. In our Rails models, the syntax looks like this:

  validates_presence_of :attribute
  

  or this:

  validates :attribute, presence: true
  

  It simply checks that the attribute is not nil or blank (whitespace). Having presence validated is great, because it frees us from having to nil check any methods that consume our validated attributes.

  But what if a future contributor removes that presence validation?

As a developers-in-training at Launch Academy, we’re constantly behind. Our inboxes are bursting with documentation, blog posts, and guides that need to be reviewed. We’re required to split our time between coursework, our “breakable toy” main projects, and numerous side projects. Simultaneously, we’re urged to engage with the wider community through social media and at meetups. This is why I’ve found it immensely useful to have solid support systems in place – what I call good information hygiene.