Complicated business logic becomes much easier to grok when you have a clear scenario in mind for the person who’s using it. I was recently working on a piece of particularly thorny logic with a new client developer for Case Commons. It had to do with subtle requirements for when and how to get permission to update a foster family’s license. We read and reread the story and the explanation, but it was hard to communicate why we were doing the thing we needed to do. We were talking in circles, and as soon as that happened, we knew we were doing it wrong.

So I pulled out the blog post I wrote a month ago, and it turned out that my friend’s family and newly adopted children were in an almost identical scenario to the one we were working on. I pulled up pictures of my friends and their adopted kids to show to the guy I was pairing with, and described the social worker, Tania, who had connected them with their new family. From then on, it wasn’t some abstract user we were talking about, it was Tania.  My pair and I discussed what would happen if my friends became able to adopt more kids, the process Tania would have to go through to make that happen, and where that information would go on the physical, printed foster family license we were implementing. Having faces and names to go with our code made all the pieces click together, when we see as the story title in tracker: “Foster Family Licensing worker sees checklist only if capacity has changed”

I’m looking forward to putting more users into more user stories to make them come to life. When each story is complete, what new awesome thing will that person be able to do, and what need of theirs will it fulfill?

The post Put the User in User Stories appeared first on Pivotal Labs.

Fast forward to last month.  I drink a lot of water and found myself often the one who took the last drop of water from the water cooler.  So I’d fetch and hoist the 5 gallon replacement jug from down the hall, sometimes several times per week.  I could have asked for help, but had thought, why be a bother when I can do it myself?  I didn’t really mind…until I found myself with a hernia from the lifting.  A minor outpatient surgery later, things are pretty well back to normal, but there will be no more carrying of the water jugs.

Fast forward to last week.  We were deep in someone else’s code and far down a rabbit hole of investigating things we didn’t quite yet understand.  There were many avenues we could explore, and we could have kept on down that rabbit hole for a long time.  But then my hernia scar twinged.  So my pair and I got up and asked the original dev, and we were on our way in minutes.

While the thrill of solving everything alone is tempting, we pair and share a team for a reason.  And if we need anything else, we can ask an entire office of Pivots every morning in the ‘helps’ part of our daily standup.  Whether in a scavenger hunt, in transporting water, or in a sea of unfamiliar code, I’m looking forward to asking for help when I need it.

The post On asking for help appeared first on Pivotal Labs.

Everything.

When you’re first getting an MVP site off the ground, you don’t know quite what you might want to track.  And might not have time to think about it.

If you log everything your users do, however, then weeks or months of data will be there for you when you need it most, to answer your questions right away.  That’s why I’m excited about companies like Heap are doing, logging every single user click.

For those without Heap invites, or if you’d prefer to use Kissmetrics, I wrote a simple gem to do the same with KissMetrics, for all your user clicks that hit your web server:   km_everything. It logs all controller actions by default, but you can set up a whitelist to give them more meaningful  and product-manager friendly names, or a ‘blacklist’ to prevent certain actions from being logged that aren’t meaningful and would use too much of your KissMetrics event quota.

Also, from what I’ve observed on KissMetrics, server-side metrics have proven more reliable.  Metrics recorded via Javascript can be off if the user closes their browser too quickly after taking an action.  Logging the metrics server-side also won’t take up any of the user’s processing power or show signs that remind them they’re being tracked.

Excited about our brave new world of meaningful ad hoc analytics with reams of user data, powered by ubiquitous metrics.  This data will then show us how to make our sites even better for our users.

The post A user metric is a terrible thing to waste appeared first on Pivotal Labs.

My current Pivotal client project is CaseCommons, using web technology to modernize child welfare and foster care so social workers can spend more time with kids and families.  We’d just completed a large set of work about court hearings, and now I was attending one. I went to see my friends finalize their adoption of two little boys they’ve been fostering, with their wedding to immediately follow.

Everything I’d done and learned paled compared to seeing the judge and social worker speak about how the kids’ lives improved in my friends’ care. One of the boys was in a wheelchair a year ago, and now here they were joyously laughing and running in circles around their new parents as the adoption was completed and wedding vows were spoken.

I talked to the social worker at length and learned things I hadn’t yet come across, like how most adoptions are with extended family members, my friends were the exception. I also saw the clerk entering the details of the court hearing into their computer system, which looked like it hadn’t been updated since the 1990s but it still was blazing fast. They’re not using our product yet, which is much more streamlined. But they’ll expect it to be equally responsive.

Now, whenever I’m doing a feature or fix for social workers, I see Tania’s face as she hugs the children and speaks with my friends about the kids. When I work on court hearings, I see the clerk navigating so quickly to enter in all the many details.

I won’t always get to work on helping people help kids.  But when I move on to my next Pivotal project I can’t wait to set aside some time much earlier on, to look users in the eye and truly understand how what we’re building will make their lives better.

The post See Your Work Product in Its Natural Habitat appeared first on Pivotal Labs.

Christina: I’m curious about pair programming and would like to learn more about your experience working at Pivotal Labs. How does pair programming actually work?

Trace: Pairing just means we both work together simultaneously, but beyond that there are many ways to do it. When creating new code, a favorite idiomatic way to do it is ping-pong pairing. One person writes a test, then (sometimes) says ‘ping,’ then the next person writes the code and the next test, then says ‘ping’ etc. You can get a great groove going that way. There’s also ‘driver-navigator’ where the navigator is the brains and doesn’t touch the keyboard, then tells the driver what to do and they type it. that’s a great way to teach and learn if the navigator has knowledge and context and the driver does not. Much of the time pairing is just free-form and collaborative, especially when planning architecture or investigating bugs.

Christina: Do you work with the same person on every project? Do you choose who you work with?

Trace: Our project has 20 devs in 5 teams of 4. We choose a new person to pair with every 1-3 days within our team, and rotate teams every 2-3 months. We also often cross-pair with members of other teams. At Pivotal it ranges from larger projects like mine to smaller 1-pair projects where the same two folks work together for a few weeks.

Christina: Are you paired with someone with the same level of skills/experience?

Trace: I’m sometimes paired with people who don’t know things I know, and I get to teach them while pairing. There are also a lot of people who know many things I don’t, and they get to teach me. Much of the time folks are about the same level but because breadth of knowledge is so vast, there are always things to teach and learn.

Christina: What is the average length of a project? do you work on each one from start to finish or do you rotate and work on projects at various stages of development?

Trace: Projects tend to be about 2-3 months. Some as short as 3 weeks for a startup’s Minimum Viable Product, sometimes 6 months or longer for a large government application or a project for an established business. Pivots often switch projects every three months or so, sometimes it takes a bit longer on the larger projects.

Christina: How have you liked your experience working at Pivotal?

Trace: <3 <3 !

The post A Student Asks about Pairing appeared first on Pivotal Labs.

Friday night, we warmed up with the GORUCO pre-party here at Pivotal Labs. Those who braved the thunderstorms to get here that night were treated to piles of chicken wings, bartenders serving directly from the Pivotal beer fridge where we all usually just help ourselves, a full open bar and some delightful Ruby-flavored conversation. I spoke with someone who had come all the way from India just to come to GORUCO, as well some of the Hungry Academy folks, up here from D.C. as a prize for winning a contest. The lights were turned on by 11pm so we could all be in good form for the long Saturday ahead of us.

Dr. Nic ‘DrNic’ Williams started us off in the morning with a talk about deployment. A key theme that stuck in my mind was to consider how the tools we use affect our thinking. For example, that’s why we don’t build enterprise on-prem versions of our apps.

Matt Wynne was next with his talk on Hexagonal Rails. He guided the way towards breaking down large interconnected Rails apps into modular, easily testable, maintainable components, making many references to Ruby’s SmallTalk roots. Having recently worked on an app with a test suite that took over an hour to run, I clearly felt the pain he was describing and look forward to implementing his recommendations in upcoming projects.

Francis Hwang then took the stage to talk about our ‘Front-End Future’. Thick Clients using Backbone.js, Ember.js and the like are becoming increasingly pervasive, and for good reason: it can make apps so responsive to users that they don’t know they’re using software. He described when using thick clients would or would not make sense. After the talk, there were several good-natured jokes about how much Javascript was being discussed at a Ruby conference, but that was exactly Francis’s point: we can take the great values we’ve built as a Ruby community and continue to apply them even as we’re using Javascript-based tools more and more in our apps.

All that was much food for thought and conversations over lunch. BBQ meat, tortillas and chips, and guacamole were all piled high with the food we got from the aptly named Mexicue. The line snaked through several rooms but moved quick, and while waiting we had a good chat about TDD in startups.

After lunch and later on in the afternoon there were a series of Micro talks: 10-minute talks on Javascript packaging, MacRuby, API caching and high performance caching, and several other topics. I enjoyed the format; the bite-size talks were well-prepared and were just long enough to go into some depth.

Justin Leitgeb had the first full-length talk of the afternoon, all about sensible testing practices, and walked us through a good mnemonic acronym to keep in mind as we write our tests. What’s not to love about CUPID:
C: Consistent Distance (Integration? Don’t stub. Unit? Don’t integrate.)
U: Unstubbed. Don’t stub anything that isn’t yours
P: Pyramidal (the most unit tests at the bottom of the pyramid, some integrated subset tests in the middle, and just a few end to end tests at the top)
I: Idempotent (Always run specs with –random and kiss test pollution goodbye)
D: Distinct.
His talk had many quotable quotes. My favorite was: ‘In a project that I worked on, one single bug caused 124 tests to fail. I was so perplexed I didn’t know which bridge to jump from.’

David Chelimsky’s presentation reminded us that while DRY stands for Don’t Repeat Yourself, it really means ‘Don’t Repeat Yourself’ unless that doesn’t make sense. For example, if you reduce duplication but that creates a new dependency, that increases coupling of things that shouldn’t be coupled and reduces the quality of your code. He also showed a great example where a Rails route file was de-duplicated completely, leaving a completely unreadable mess of CONST1 + CONST2 + CONST3 code on every line.

Jim Weirich gave the last presentation of the day, opening our eyes to the power of what Rake can do for us. For example, Rake has a lot of native support centered around file lists. He showed an example where he kept a set of images in one directory and had Rake create thumbnails for those images in another directory. Rake notices when a file hasn’t changed, so running it a second time skips the thumbnails it’s already built.

Video of all the talks is available, and fellow Pivot Kris Hicks uploaded his photos of the conference. Check ‘em out!

Once the presentations were done, the GORUCO staff donned their sailor hats and we all headed over to Pier 40 to get on board our yacht cruise. Hungry devs and their significant others were talking about the best algorithm to most quickly make their way through the meat, salad, and pasta serving stations on the boat’s 3 floors. The 210′ vessel was brand new; the staff told us we were the first to spill our drinks on the carpet! The top-shelf open bar was well-provisioned and it’s not surprising that when the very eclectic soundtrack started playing Adele’s ‘Someone Like You’, a large group got an early start to the evening’s karaoke by screaming it at the top of their lungs. I saw the video, but it was deemed too hot for this blog post.

We had great conversations on that boat, technical and otherwise. I spent a bunch of time hanging out with a large group of dev leads from NYC’s hottest startups. One guy was telling me about a day-long pairing exercise that can expand our horizons. Can’t wait to try it!

The boat ride ended with a pass by the Statue of Liberty, directly below a huge fireworks display. The warm night and close view was perfection.

After we returned to Pier 40 and disembarked, many folks headed over to Karaoke Cave in the Village to sing until the wee hours. I couldn’t make it, but I heard that it was very fun and memorable. So much so that the people I spoke with couldn’t remember some of it! But apparently, Dr. Nic can really hold a tune.

Thanks again to the GORUCO organizers for putting together such a great event. Looking forward to next year!

The post GORUCO 2012 Recap appeared first on Pivotal Labs.