I’m usually early, so the people in before me are those that make the journey from “Noo Joisey”, bless their hearts. I’ll sit and talk, or I’ll open my MBP and work on personal stuff, like blogging.

Breakfast is made by one of our lovely kitchen staff. Im a fan of the eggs and sausages, but there’s also fresh fruit, oatmeal, cake, pancakes… All sorts of things.

At five past nine, a gong sounds and we all gather quickly for a company stand up. Any newsworthy discoveries are raised, any questions that need answering are asked, all the events are listed. We clap in unison and disperse. Many of us huddle around the espresso machine getting another jolt into us before our team standups.

This is a pretty relaxed way to start the day.

The rest of the day is spent pairing with other developers, 100%, and the support this gives you is tremendous. I know a few people who dont like it, but even they see the value in it. The rest of us love it, and often find it frustrating when we’re forced to solo.

We (the pair) look at the most important story the product manager has identified, and we discuss how to best implement it. We go to the product team, who are all nearby, with any questions we might have.

We implement our code with diligence. Diligent about quality, diligent about design, diligent not to overwork the solution (lest we don’t end up needing the code). Some pairs are great at forcing you to stay true to the red-green-refactor, outside-in philosophy. Others are strong on ‘YAGNI’. Everyone brings something to the table, and everyone can trust that their colleagues are providing value.

Its rare to think “I will _so_ need to check his code” or “What fool did this thing?!”. If you ask someone about their implementation choices, they can give you good solid reasoning for them.

Working in pairs is intense. A suitable term is ‘compression’ – we stop and play a game of ping-pong or just take 5 minutes out to ‘decompress’. It’s exhausting but liberating. Typically, the only thing that you spend your energy on is creating good product. You dont often waste energy on “he said, she said” or worrying out about pointless feature development and unrealistic deadlines.

Edit: Forgot to mention, I don’t get asked to do overtime, and I get to see my family at a reasonable time every night.

Honestly, if you need a break from the insanity. Come and work for Pivotal.

The post Being a Pivot. appeared first on Pivotal Labs.

• moving content
• refactoring domain terms within content.

I’ve identified the key areas of risk as narrative and permalinks.

Narrative

The narrative of your site/app can break in subtle and unexpected ways. It is difficult to guard against side-effects upon the narrative. This makes changes to domain terms high-risk. Specifically, a developer focused on the code can easily miss these side effects.

Here’s an obvious, and well guarded story:

Given I am a user
When I visit the user's profile
Then I see their latest activity

That one’s simple, if you move the latest activity to a sub-nav, this story will break (that’s a good thing). In this case, you could ask the product owner, “In the past, having a user’s activity visible on their profile page was desirable. Are you sure you want to lose that?”.

However not all narrative is this cut and dry. Consider this story:

As a user
When I visit a member's profile
I can see a list of pages the member is interested in.

Then, along comes a new unit of work, “Rename all pages to interests”. This seems reasonable, and so you finish the story. The test for the ‘pages’ the member is interested in continues to work, however the member profile ought to lose any reference to ‘pages’. The new domain term ‘interests’ should be used instead.

Now your tests are using misleading or confusing language. You need to update all your stories to use the new term. This can get onerous quickly, but it’s vital for consistency.

I’m yet to find a satisfying technique for mitigating this risk. It’s hard enough keeping the modelling clear of inconsistencies.

This same change to narrative also affects ‘curators’ of ‘pages’. They no longer curate ‘pages’, they now provide ‘interests’. Do we want the curators to go through this mental hurdle, or the strangeness of ‘managing an interest’ versus ‘my interests’? Suddenly a curator has a list of ‘interests which they maintain’ and a list of things they are ‘interested in’.

The best way to mitigate the ‘broken narrative’ risk is to stay strong on short, testable stories. Fast turnaround between development and acceptance is also valuable. The fast feedback cycle is less overwhelming for both developer and product. The chance to think about risks is stronger when the story is as uncomplicated as possible.

The risk of broken narrative is just another reason to avoid this internal desire to take ‘big bites’.

Permalinks

Permalinks and long lasting links, are any URLs for which permanence matters. E.g., the permalink to an article on your blog from some outside source. The risk of broken permalinks can be readily mitigated in your intrgration tests. To achieve this, you need to make sure that product is thinking actively about permalinking. Impart to the product owner that permalinks must be (as much as is possible) explicitly called out in stories.

Permalinks in cucumber tests

Here is an example.

A story in your backlog calls for content that must be available in a permalink. You write a scenario like this:

Given I am a visitor
And there is an article
When I click on a permalink for the article
Then I should see the article

The important term in this story is ‘permalink’ – whenever a step definition calls for a permalink, it needs to use a constructed link:

visit ('/articles/#(article.slug}')

Do not use Rail’s (or your framework of choice) magic:

visit(article_url(article)) # won't capture intent

This way, if the permalink goes away, the test fails, and the intent is clearly captured.

 The many unseen dependencies

To complicate matters, a moderately complex site usually has a swathe of references to the content you are about to move/refactor. The term is often used in abundance, E.g. ‘Post’ or ‘Job’ or ‘Activity’. The page might be accessed from several places, E.g. messages are available from the ‘User -> Messages’ nav item, the ‘”My Favorite Lolcats” group messages’ page etc..

Key take-aways:

• Fast feedback loops. (small testable and deliverable chunks of work)
• Oodles (lots) of product owner/ux designer/copywriter/developer collaboration.
• Changes in domain terms need to be kept consistent throughout your tests.

The post Broken permalinks and narrative, the pitfalls of moving content. appeared first on Pivotal Labs.

Tenderlove explains YAML exploits

Tenderlove explains YAML exploits in great detail, and with his usual panache

http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html

The post [NY] Thursday Standup appeared first on Pivotal Labs.

If that is not bad enough, old technologies get reinvigorated, like people taking up Vi, Lisp, NeXt… :)

So if you’re like me, are ‘time poor’ and want to get something valuable out of your precious personal-project time, then be brave.

Today I started on a small gem, to help people track what’s taking a lot of time in their Rails boot process. I needed to test. I use RSpec at work, yet I fell back to my default, minitest, because it comes for free with Ruby and is pretty straight forward for small work. I noticed, for the first time, that minitest has a BDD style syntax. Feeling brave, I used it.

I’m glad I did.

It will confuse me when I switch context back to work, then back to the gem. Nevertheless, I enjoyed using something so simple but slightly nicer to type, read and comprehend than:

def test_it_wants_to_have_lots_of_underscores
end

You would think that using a bunch of differently named expectations would be annoying. It wasn’t. It stretched my mind in a short amount of time, which is more satisfying than the string of passing tests in my little personal-project.

The post Being Brave is fun. appeared first on Pivotal Labs.