“Drinking the Kool-Aid™” How We Create Value Alignment

Saturday, May 4, 2013

Over my four year tenure at Pivotal Labs I’ve heard it a lot: “You guys really drink the Kool-Aid around here, don’t you?” and I’d shake it off with a joke, “Yeah, you can grab anything from the fridge you want, so long as it’s powder-based fruit punch.” I thought I knew what they were getting at, we’re pretty rigorous about things that are radically different from the way most software developers work – TDD, pair programing, and a common start time to name a few. But it takes more than common practices to build a culture that is so strong that it consistently elicits cult analogies.

First off, I’m not excited to be called a cult member – the term is derogatory and carries a lot of baggage with it. But if we look at this definition from Wikipedia, the word cult is a ”term for a new religious movement or other group whose beliefs or practices are considered abnormal or bizarre by the larger society.” While we’re not “religious”, I would say we’re a “movement” to change the way software is made, and our practices intentionally push the boundaries of what most organizations are comfortable with. But what makes a cult is beyond practices.

I said I thought I knew what people were getting at, but I didn’t fully understand it until recently when I was sitting down with a candidate who was on the edge about accepting a job offer at Pivotal. She had been trough our usual rounds of interviews and had some really good questions. I did my best to answer them honestly. At the end she thanked me and offered, “If nothing else you’re all very consistent.” I indicated I wanted to know more and she shared that she had also talked to pivots at meetups and even overheard a couple of us on the train and apparently we “… all say the same things about [our] company.” She had to leave, so we said our goodbyes, but what she had said moments before was still washing over me.

How is it that we’re so consistent? Even when we think no one is listening we say the same things that we say when trying to attract new talent. For my specific situation, I wasn’t glossing over any of the parts of our company that are feeling growing pains; I felt confident that reality was not only good enough to stand on it’s own, but that it was the right thing to say. I wanted her to make an informed decision about coming to work with us – one of the hardest things to do is work with someone who doesn’t want to be there. I imagine school teachers feel this way a lot of the time, compared to other classroom settings where students opt-in.

Okay, being open is a pretty good thing, but it doesn’t fully explain how I was giving the same message that the rest of my coworkers were giving. Each person has a unique perspective on life, and there certainly isn’t someone coming over the speakers every morning telling us what to think. Upon reflection, I think the reason we have a common appreciation for our work place is because we pair program and rotate through projects. While I’m sharing my technical skills when at the keyboard, I’m also learning about what’s going on in the company, on the team, and with the individual between keyboarding times (see future post “Why Slow Tests Aren’t Always a Bad Thing”). Face-time, and pairing specifically, homogenates a workforce.

This constant sharing of ideas and perspectives quickly creates a value alignment without anyone ever having to say what those values are. We even pair when interviewing so we’re selecting for those values from day zero. And since we have this strong alignment, it’s easier to identify pivots as a group, or a “cult” if you must, rather than as individuals who works for a faceless brand. If you want your company values to be represented at all levels, you have to talk about and challenge those values every day so that there is shared understanding, and pairing is a great way to do just that.

As it turns out, that interview candidate accepted the job the day after we spoke. I also checked the fridge, and though it is well stocked with a variety of beverages including fancy tea, Kombucha, over thirty kinds of beer, and a plethora of juices, Kool-Aid is no where to be found. We understand why we’re at our job better than anyone else in the business, plus we can message those values even when we think no one is listening, and that’s a powerful thing to find in the workplace.

Get Personal, Get Feedback, Get Better

Will Read

Friday, April 26, 2013

One of our directors shared this article with the managers here at Pivotal Labs about having a personal retrospective. It immediately sparked a healthy debate, and I latched on to the idea because I think it fills a very real hole in getting feedback. We do great at gathering, weighting, and aggregating feedback from a pivot’s peers and delivering that in a constructive way. However, we don’t have a great way to get direct feedback on a level above the day-to-day pairing feedback. To see if it would be useful at our company, we needed to try it out so I volunteered. In addition to learning about myself the personal retro had several unexpected, positive effects. My experience was very personal and I’d be happy to talk about it in more details in person – what follows here are my findings on how to run one successfully in the hopes that others will find this tool useful as well.

I think there were at least four key elements to my personal retro that made it work well:

Be quiet and in the background. Have a facilitator, you can not host this yourself
Pick the right people and set expectations
Pick the right questions to ask
Be in a frame of mind where you really want this feedback (introspective, courage)

I initially thought, “I’m good at leading project retros, I should be able to lead a retro about myself.” I’m glad someone else suggested that I have a facilitator and that I listened. It was intense enough listening to feedback, I can’t imagine trying to stay impartial and lead discussion while soaking it all in. I asked one of our pivots who has not only led retros, but also facilitated inceptions – I knew he could handle the job and be professional about it. He took my questions and prepared his own notes ahead of time and asked me clarifying questions. Since I was doing my best to be quiet to prevent influencing opinions, he also made sure that before we moved on that I had the clarity I needed. I was on the opposite side of the room from the facilitator, so most times I wasn’t in the field of view of the speaker and they addressed me in the third person “…he does this very well”, or “Will always…”. This went a long way to making me feel more comfortable and hopefully made the reviewers more comfortable too.

Picking the right people was tough. I wanted to get feedback on all parts of my job. I’m a developer, a team lead (anchor), a manger, and probably another two less official hats. I wanted to know about how I’m doing as a pivot in all these areas. My review team consisted of:

My manager
A fellow manager
One of my reports
One of my team mates
and …

While I respect and value all four of these people’s opinions, I wanted to have someone in the room who saw me differently. Someone who I had a rough experience with. My experience has often been that you can learn a lot more when you disagree and so I wanted that person in the room too. She declined the retro so I invited a friend and rising pivot to be my fifth reviewer. I felt five was the right number because it was big enough for diversity, small enough to be productive, and odd numbered if any voting needed to take place.

In my invite I shared the above article. I shared my intended questions for discussion. I shared the invite list so that if someone didn’t feel comfortable reviewing me in front of the director of the office he or she could gracefully bow out. I made it clear that this was optional.

Not everyone was a match to give this kind of feedback in a group setting. As we do more personal retros I suspect we’ll get a better feel for who is well suited to giving feedback in a semi-public environment. The quantity of feedback I got seemed to be directly proportional to the seniority of the reviewer, but the less-senior pivots provided their own unique perspective and insights that I would keep if I was doing it over again; meaning that I appreciated the spread, but it would be folly to expect a greener employee to produce all the value, so set your expectations appropriately.

Picking the right questions for me was the most emotional part of this process. I wanted to be specific so as to provide direction to the group – “What do you like most/least about Will” was not going to cut it. I’ve gotten some feedback with my manager and I really wanted to focus in on what it would mean to make some of those areas better. Before I could do that, I had to share context and concrete examples with this group so they could paint me their own picture of how I am perceived through their eyes. If you want an exercise to get at these questions, you could probably stand at a whiteboard by yourself, create the three columns, and group them together and prioritize like you would in a normal retro. I wrote down my questions and sent out the invites at least two weeks ahead which gave me plenty of time to think about what kinds of answers I wanted from people, and what examples I had if they needed clarification. For me, I’m an introspective guy and these kinds of questions are always rolling around in my head, they’re what drive me to be better, but until now I only had myself to measure against. For most, it might be helpful to go through an annual review first to get some solid manager feedback and have a year of experience under your belt before embarking on a personal retro.

Once you’ve picked the right people, picked the right questions, the only thing to worry about is yourself. In order for this to be useful at all, you’ve got to want to know more about yourself, and you’ve got to be willing to listen to others even if you don’t agree with them. Humility goes hand and hand with the personal retro. I was called “brave” and “courageous”, which felt good, but I wasn’t there for praise, I was there to grow. It does take some steel-clad nerves to ask a peer to speak about you. It takes guts to show your boss where you and others think you can improve. And no one can call you chicken for shining this kind of light on some of the dusty parts of your personality, but I can assure you that I still had moments leading up to my retro where I wanted to smash the eject button and bail out. This. Is. Not. Easy. But the benefit far outweighs the cost for those who are willing to try.

Experience Report: Engine Usage That Didn’t Work

Will Read

Sunday, September 16, 2012

On the project I’m currently working on we have a main portal that provides a user registration system and a generic billing mechanism. It also has several sub applications which need to know some information about the user and be able to publish billing events. With a fairly easy to articulate boundary, we thought it might make sense to be deliberate in how we organized our code – we came up with three main solutions:

One big app, just use namespaces
Create the portal and expose API endpoints over HTTP to get user data and set billing data.
Create the portal, and have each sub application contained in a Rails Mountable Engine.

Our Boulder office had been making some noise about Rails Mountable Engines for some time, gave a presentation in the SF office, and I had experience working with engines both in the dark times of engines in Rails 2.x and the markedly improved days of Rails 3.x, and even better still in 3.1+. We had need to scale one sub-component of one of the applications independently, but not entire apps as the primary usage of the system would be low-volume. We set off down the engines path…

It worked pretty well. Two months in to the project we had a retrospective specifically about how engines were working. We agreed that we had felt some pain, but overall they drove out interesting decoupling and that the cost to pull them out could potentially outweigh the little pain we might encounter in the future.

Then our team size doubled. We had multiple epics that had high priority and deadlines associated with them. We also needed to ramp up four new people which led me to reassess our choice of engines once again, not to mention that we eventually will be handing over the code to developers who haven’t seen much Rails.

The conclusion I came to was that engines had to go. Here’s the list of why:

Asset pipeline already feels magical, with engines you have to think even harder about what you’re doing and what to include in your application.js or application.scss.
Testing. Writing an RSpec request spec didn’t make sense in the engines where certain styles were expected, or a specific layout – we found ourselves stubbing out a whole lot, or putting more and more into a gem that contained shared code between the portal and the engines.
Running Tests – We had to have multiple instances of RubyMine open to get the correct load paths for the engine and the portal, constantly trying to remember “Is this in the shared gem, or in the engine?” or “Oh wait, this is specific to the engine, but it is a request spec so we need to go back to the portal to re-run that” was not unsolvable, but felt like a tax on our choice every time I fumbled.
Migrations everywhere – You write the migration in the engine, then it has to be copied to the dummy app for testing, and also back up to the main app for running request specs, now you have three copies of the same migration, all with different timestamps. Not fun when you realize you also needed to change that string column to a text column.
Everything still had to be namespaced anyway for the engines so we had the folder explosion we were trying to avoid from the One Big App solution.
Confidence – It got to the point where I found myself asking “Is this broken because I wrote it wrong, or because there’s something I misunderstood about engines?”. I could never be sure of why something had gone wrong.
Documentation – Rails Mountable Engines documentation is a small subset of the knowledge available on StackOverflow for example. If we want to make the ramp up and handoff as smooth as possible, we want to do the most vanilla thing possible so that things are intuitive or at least Googleable.

None of this was impossible, or even difficult to solve. It’s just that it wasn’t intuitive, not what a well seasoned Rails developer was expecting out of the box. It would have been a waste of our client’s time to bring a whole new team up to speed on all that we had learned about engines, rather than having one big application.

This is especially true since the only semi-real-payoff was that it made us isolate our sub-application code from the portal code. I say “semi-real” because the boundary was artificial – the reality was that the sub applications needed to know about the user and his account, and anything we built out for billing was really a dependency of each of the apps. This was different from a great engine like rails_admin that really is a drop in and has no domain-specific dependencies. Here we had nothing but domain-specific dependencies and now, by removing engines, our code and our domain are back where they belong: together.

UPDATE *
Engines really are great and there’s lots of situations where they can be really powerful. Boulder Pivot, Stephan Hagemann, had these additional tips that I wanted to share with you.
Regarding RubyMine and running specs: there is a simple way to make RubyMine run all specs in all engines. It will make all engines modules with their own “RubMine root”, which fixes spec runs. http://pivotallabs.com/users/shagemann/blog/articles/2008-intellij-modules-in-rubymine-
Regarding migration duplication: You can have an engine or app that requires others run their migrations. Check out the migrations run by the main app in this sample app: https://github.com/shageman/the_next_big_thing
Regarding testing: If an engine is relying on some layout or style to be around, it should depend on it and include it (potentially by way of another engine).

Executable Documentation

Will Read

Sunday, June 3, 2012

I try to avoid writing static documentation. It gets old and out of date as soon as the next person comes along because it is logically far away from the code it describes, so event the best intended developers won’t always be aware of the documentation dependencies. Since working at Pivotal I’ve enjoyed writing tests first with RSpec, which results in one form of executable documentation to describe behavior to other developers working in the code base. But what about when you need to express behavior to people outside of your code base? Maybe your stakeholders have a company requirement of documentation, maybe you’re trying to entice third party developers to use your new HTTP API, or maybe you just want people to install your gem, what then? Your audience matters, and there’s a variety of tools out there to use depending on your needs.

Human Readable

Cucumber is one tool that can be used to fill this need. It’s designed to be a DSL for creating DSLs to describe your application. It has a nice attribute that it is very human readable. You can then use tools like Relish to publish docs from your Cucumber suite. The drawback is that you put a lot of effort in to expressing what you want in English, which is great if you’re really showing this to non-technical people, but it can be an over optimization if your readers have some technical context.

Dev Readable

In the case where your audience is an outside developer, something like rspec_api_documentation might be more appropriate. It layers on a DSL to your familiar RSpec DSL that lends itself to HTTP APIs. This is great because your RSpec tests become more expressive without the overhead of defining the DSL yourself. From there, you run a rake task to generate HTML. Your spec runs will fail if your docs get out of sync, which should be never if you have CI. The web is an easy venue to consume this kind of information, but the tool doesn’t let you editorialize much beyond the description of the resource and the parameters.

The Best of Both Worlds

One of our open source projects here at Pivotal Labs is Jasmine, a JavaScript testing framework that runs in the browser. Unlike Rspec where you need to have ruby installed and a database set up and so on, everyone has a browser. Check out the jasmine docs and scroll to the bottom. That’s right, the examples are tests, the comments are close to the tests so when the test fails you know to update the text as well, and now someone has a working example of how to use Jasmine all in one. The page itself is generated using Rocco, a Ruby port of Docco.With the combination of docs generated from tests, and tests that run in the browser you get this perfect blend of readable, easy to maintain documentation that is available to your entire audience.

Sometimes you have to provide documentation, but that doesn’t mean it has to be outdated. By creating executable documentation you can have confidence that the code and docs are staying in sync. Consider your audience carefully when choosing how you will document your software and know that there are more than a handful of options available, one of which will probably suit your task well.

Pivotal: Why It Works

Will Read

Thursday, April 26, 2012

My name is Will, I’m 30 years old, and I’m a Pivot. In my three year tenure here at Pivotal Labs, I’ve found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.

My story starts with breakfast and ends with trust. Each piece plays in to another, and the result is an environment where teams are autonomous, culture and knowledge spread quickly and organically, and communication is never a secondary priority. Our clients see the results in the way which we interact with them to deliver exactly what they need. My coworkers feel it when they realize they control their own destiny and have all the power to make their situation better. You hear it when you listen to pivots like myself or others who appear at conferences across the globe. What we have here is special.

Breakfast – The Most Important Meal of the Day

We have breakfast prepared for us by an outstanding catering staff. It is delicious and you should be jealous if only because it means that there’s one less thing I have to do in the morning. It isn’t just food though, and it isn’t a ploy to eek out more hours from pivots like other companies that might provide dinner in hopes that you don’t leave till midnight. No, breakfast is much deeper than eggs and bacon – it’s a time to cross pollinate, to talk to the pivots who aren’t on your team to share in things both work and non-work related. It also gets us to the office at the same time, which makes it easy to pair together for eight hours, then we all go home together at six, and breakfast leads us right in to our all company standup.

Standup – You’re Not Alone

Yes, the whole body of developers participate in the biggest, most high value standup you’ve ever seen. At pivotal you’re never alone, and company standup is just one of the ways we assure that is always true. When you have hired the best (more on that later), why wouldn’t you want them all to be on every team all the time? Since mitosis of humans hasn’t left science fiction yet, we have to settle for osmosis. We go over who is new or visiting the office, who needs help, and what interesting stuff has come up that might be relevant to other teams. You can read our standup notes right here at pivotallabs.com/blabs. Culture starts here too. Company jokes develop over time as we all gripe about the bumpy release process a particular tool is going through. Company standup also makes it clear that it is okay to not know things. Let me say that again: It is okay to not know something.

Another pivot, Davis Frank, shared an analogy that resonated, but since my Bruce Lee knowledge leaves most wanting, I have adapted it to a much geekier Star Trek take. Being a pivot is akin to being a senior officer on the bridge of the Enterprise. We hire people who will speak up and collaborate, people who will work to make exploration sustainable. We all come to Pivotal Labs with our own expertise like Jordi with his engineering skills, and Beverly the medical doctor, but the very nature of working with startups and our other clients means that we are always going “where no one has gone before” with respect to code, and sometimes the ship’s councilor has to hot wire a tricorder. There is no manual on how to build Twitter or Groupon. Pivotal never gave me the answers to those problems, that’s not how we work. Instead, Pivotal, like Star Fleet, exposed me to a lot of problems all the time and gave me the resources and teams to help me solve them as I encountered them.

Pair Programming – The Trust Builder You’re Already Doing

After company standup and our own team standup, we pair program. That means two people, one computer, all day. It isn’t half as radical as it may seem at first glance. Has anyone at your standups ever asked for help? Did someone then go over and sit with that person at one computer? I suspect they did. Do you do code reviews? Then aren’t you really asking your team to share coding knowledge and culture? Think about it. This is what pairing is all about, we’re just set up to do it a lot more often. And getting back to trust, pairing turns a potentially threatening code review process in to a co-ownership process.

Pairing builds trust in all directions. It builds trust between the pair and the client accepting the user stories because I know that two people have thought about this problem. I also know that any cultural nuances that one pivot has picked up are being shared inline with the other pivot. Pairing builds trust between devs. If you talk about code with someone for eight hours a day you can’t help but understand how he approaches problems. That said, you may not always agree, but at least you understand, and you can have much deeper, more meaningful collaborations when that understanding is in place. Pairing develops trust between the team and the individual because I know that if a feature fails, I am not alone in the failure, and if the feature succeeds, I will have good company to celebrate the success.

Talking about code for an entire work day is hard, I won’t pull any punches there. Think about the last time you were in a long white boarding session. I might have been needed, and possibly energizing, but I bet you also needed to decompress for at least fifteen minutes after. Pairing is like that, so we find other ways to communicate that also happen to feed in to the trust: Test Driving. Write tests first; that way, as your pair, I know what we’re about to work on for the next five to twenty minutes. Writing tests first is a great way to enhance your pair’s understanding of how you’re thinking about a problem and the potential solution. Once you have the test, it has the added benefit of speaking to future devs who might work on this code and communicate what it was meant to do so they can make an informed decision whether you’re available or not. Speaking of which, since we rotate between projects, someone not being there is more than just a possibility, it’s just a matter of time.

Rotate your Pivots Every Six Months or 10,000 Spec Runs

The average pivot is on a project for 3-6 months, some stay longer, some are shorter if their leadership is needed elsewhere, but in general you can count on seeing a good number of projects in three years’ time. On one project you might make a JSON API, and on the next you’re up to your eyeballs in JavaScript, HAML, and CSS. Then it might be off to help a company scale and tune performance. We swap people around and expect them to be adding value on a new project day one. We do that by standardizing on a few things about our workstations. For starters, every computer is basically the same minus the project code itself. Our ops team has done a great job of having an updatable workstation image that is under test so they know when it breaks. After many holy wars, we’ve also come to an arrangement about which IDE and keybindings to use. The choices may not always be “the best” when getting down to specifics, but it is one less hurdle to jump when you find yourself on a new project with new faces, new clients, and new domain – at least your computer feels like the home you just left. It also means I don’t have to think about how to set up a machine when starting a new project, the collective knowledge of Pivotal workstation config is captured in our machine image.

Rotation is a razor sharp double edged sword. Your average dev working for a product company might switch teams once in three years. Meanwhile at Pivotal Labs, I’m seeing new problems and new solutions at a rate 3-6 times that. It means that I can demonstrate loyalty by staying at one company, but the experience of working for ten companies in that same timeframe. Rotation makes our best pivots that much better. The downside of course is that someone who demonstrates loyalty but possesses the experience that is characteristic of a senior pivot soon finds himself being invited to take on lucrative and dazzling roles elsewhere. I can’t begin to explain the sadness and frustration I feel when a pivot leaves the company, but we also can’t afford not to train up our employees. It is the same high quality that makes pivots hirable that brings in the steady stream of clients to Pivotal Labs. If we stunted or slowed that growth any way, it would weaken our offering in a way that would undermine much of what is good about Pivotal Labs.

Hire the Best

We are unwavering when it comes to hiring. When you come in for an interview, you write code on real product because that’s what we’re expecting you to do when you’re here everyday, not solve brain teasers at some white board. We want to know if you can communicate, and we want to know if you can learn and adapt. Pivotal throws pivots in to uncharted waters a lot and we expect pivots to swim. They always do because we hire great swimmers. Hiring great people means we don’t have to spend a lot of time with formal training, or managing, because people are good citizens within the company. Also, hiring great people who raise the average and are put in a place where they pair and rotate means that the average really does go up for everyone. This has an awesome effect on morale, and serves to give us all the confidence that we need to takle new problems. Having the best means that teams can be autonomous and we can trust them to interact directly with the client eight hours a day. We don’t have any need for the “heros” or the “ninjas” who can strap on headphones and have a caffeine-induced flow session. We hire largely for technical aptitude and ability to communicate which is not most developers. When you’ve hired the best for this business, delivering features comes naturally.

Focusing Priorities with Pivotal Tracker

The real magic of Pivotal Labs that you might not notice at first is Pivotal Tracker. It may look like an ordinary project tracking system, but it does two things very well that most software fails to do: 1) Tracker forces clients to prioritize the work we do for them, and 2) it serves as a central communication piece. The former is very important to the success of the project. I’d like to think that because of all the other things we do, we produce more features period, but that’s not the whole picture. Because everything is prioritized, we produce the right features, or at least the features the client wants the most. It is hard for a client to be dissatisfied when we’re always working on the most important thing. We know it is the most important thing because we’ve talked about it. Tracker is the main talking point in our short, weekly meeting so we know that our client wants these features first, we talk about any technical needs we have on our side, and discuss the story details beyond what is typed in Tracker. Remember how I said it all plays in together? Well since we all sit together, and we all trust each other, it greatly reduces the need to spec out every last detail – most of the time we have enough context to make well informed decisions, or we can turn around and ask our client for clarification, or baring that we deliver a story and get some great feedback in the form of a rejected story. At Pivotal, you’d have to work really hard to not deliver what the customer wanted.

Feedback – Always, Everywhere

Being an Agile shop means we’re always gathering feedback and looking for ways to do our job better. Each project is different, so we have regular retrospectives to help us surface and adapt to those differences. This exercise is focused on getting better, and depends on honesty and therefore builds trust in a team. This goes hand-in-hand with hiring the best, because the best speak up and the best aren’t afraid to say something scary or controversial. The best lay their ego aside in order to improve a team, project, or a company. I strongly believe that, if left alone, the right people with retrospectives would arrive at a process that looks a lot like Pivotal Labs does today – in fact I would argue that’s what happened when the idea of Agile was first put to paper by Beck, Fowler and the rest of the Agile work group. Get and give feedback, act on that feedback, that’s the core. Action however, doesn’t always lead to success at first try.

If at First…

In fact, taking action leads to failure a bunch. Since the set of problems, both human and technical is huge and enormously complicated, it is reasonable to assume that most guesses at actions would end in failure. But guess what, we fail, get feedback, take action, and over time, those actions lead to successful actions. Often times the success is very different than it was originally pictured. We also have the benefit of having that experience that can now be applied to a future project. Pivotal Labs is good about making it safe to fail. Read that again, it is safe to fail here. Why? Because we start with the best, then we give them a lot of experience, and we trust them to make the best decision given the information and experience they have. And because we’ve hired for it, teams own their failures, and they’re intrinsically motivated to do better. No one has to sit over their shoulder and tell them it went wrong. They know, and as a matter of pride they’ll fix it. Most importantly, they have the skill set and the resources to fix it.

Greater Than the Sum of its Parts

By now you should be hearing it in your head, that it all feeds in to itself. The whole thing works because it is complete. Each part, start time, pairing, test driving, hiring, clear priorities, and feedback contribute more to the system than just its stand-alone value. The pieces are all obvious, but how they interrelate and build trust across the organization is what makes Pivotal an outstanding company. My name is Will, and this is why I’m a pivot.

If you’re looking for developers, and you want to get the most important things done, I hope you’ll consider becoming one of our clients, we do web and mobile work and you can drop us a line at sales@pivotallabs.com. If this resonated with you and you’re looking for a job as a developer, please send your resume to pivotallabs.com/jobs.

Expectations: What if Life was a Rails Project?

Will Read

Monday, July 12, 2010

In any consulting job, a project truly fails when expectations are not clearly communicated. In Ruby, we have a great tool for communicating expectations about code. What if we applied that same tool to real life? The anchors at Pivotal Labs have a wealth of knowledge about what elements contribute to a smooth running project. I have my own ideas about what makes a project fun to work on. Below is a very short start to what I like to see about a project going in. This is not to say that a project that fails this spec is “bad”, just that I feel a lot better when a project already has these things in place.

Check out the Pastie

Pair Benefit #458: Choice

Will Read

Thursday, July 1, 2010

Though I am certain someone could do it, it is hard to dispute the connection between having choices and control over your daily work and overall job satisfaction. The people with more power to govern themselves will typically report that they are more satisfied with their jobs. This is why pairing can play a huge part both with picking who you work with and what you work on.

The difference between a 1 pair project and a 2 pair project is 3 choices vs. no choices in who you work with. You can like everyone on your team and be pleased with their work, but you can only sit side-by-side with one guy for so long. When you go up to two pairs, you suddenly have a choice that wasn’t there before, and it is there in a big way. Tired of Joe? No problem, you and Rachel haven’t paired in a while, so make that happen.

The reason people don’t need “pet projects” is because we get to pick who works on what at the top of the backlog. Yes, I have to do some grunty work, but I also get to side-step some things that I’d rather not do. More importantly, you pick what it is you work on. So now you’re doing something you chose, vs. something that was assigned to you. You as an individual have a personal investment in seeing that task through.

The work place can be filled with all kinds of challenges, and can seem oppressive if you can’t exact any control over it. By pairing and having an option to rotate, you get to pick your work and pick your coworker every single day. And choice is a great way to stay happy at work.

Write Once, Run Anywhere

Will Read

Monday, May 3, 2010

In response to some recent web browser related debates:
http://sachin.posterous.com/the-web-sucks
http://techcrunch.com/2010/04/30/joe-hewitt-web-development/
http://yehudakatz.com/2010/04/30/the-web-doesnt-suck-browsers-are-innovating/

The web has long since tried to help developers realize the [perhaps misguided] promise that you can write software once and run it anywhere without modification. This might have even seemed feasible when the only real consumer web-enabled device was a desktop or laptop PC with a fairly standard monitor resolution, keyboard, mouse – predictable. You could even bank on IE probably being the browser of choice at one point, like Netscape before it.

But then we started getting choices. Your screen might be 17″, it might be 27″. You might be using a keyboard and tabbing around, or you might only have a finger for input. Both hardware and software have been bringing their A games. Meanwhile web developers cried out for standards adherence in an attempt to create the One Ring to rule them all (but with less fiery eyeballs and dead hobbits).

Then phones made us wake up. The iPhone made the first strong compelling argument to target your web app for a specific resolution, input mechanism, and browser. Now we had two views for our website, the iPhone, and the ‘everything else bucket’.

The ‘everything else bucket’ is probably as good for the web as the No Child Left Behind program is for public education. Sure it has merits, like getting stuff out the door, but for tailored user experience, you’d need a lot more teachers and class rooms, or in our case developers.

Subsequently, yeah iPhone, iPad, Android, WebOS apps rock for UX when you do ‘em up right, but only because a business has placed value in that UX. Conversely, they’ve said that the UX between Firefox and Safari on a desktop is “pretty much the same” and there’s not a lot of value in differentiation.

What I would be curious to see is how much MVC the Rails Way has paid off in this time of many platforms. My guess is that it hasn’t been nearly as helpful as having an easily consumable API. Yes, there’s overlap in those two areas, but picture an API written without knowledge of the MVC pattern and a well structured MVC web site where you now want to add specific view code for PlatformX. I think nine times out of ten you’ll see the API gets more mileage because the views aren’t one-for-one on different platforms.

What might be a separate menu on a phone, could also be part of a side be on a desktop-like presentation. Now you find yourself writing new controllers, so all you’ve really saved on is the model code, which Rails writes most of that for you – you are only slightly better off than if you decided to write the thing from scratch.

It’s easy to argue for this implementation, or that, or ‘…if you rearrange things, then you can…’, but the problem is that there is a cost associated with catering to any specific platform. Developers have to know the nuances of those systems and be able to test in that specific environment. Then you have to balance that cost with the user base you can expect to gain. Until it becomes so cheap to know all the differences and simulate the all combinations of environments, targeted UX will continue to be a low priority for businesses.

Since I know we aren’t all holding our breath for that day, let me pose what may sound like an even more ridiculous solution: What if you could only get to certain parts of the web using a certain browser? Just like some software isn’t written for the Mac, or Windows, or Linux today, what if you could change the expectation that I can surf to any web site with any browser? What if we went to google.com and it said “Sorry, please use Chrome” would that be so awful? Or I went to cnn.com and it said “This site requires Firefox.” Would you do it if the user experience was amazing?

The two expectations, ‘I can go anywhere’, and ‘I can run my software anywhere’ are what cause us developers to beat our heads against the wall when a new browser comes out, or one deviates from the standard. I think if you can find a way to manage those expectations you can get down to brass tax with your users.

"Obnoxious" Means It's Working

Will Read

Wednesday, March 31, 2010

Back at the ‘Labs we start off every morning with breakfast at 8:45, then at 9:05 someone rings the cowbell. The cowbell lets everyone know, “Hey we’re doing stand-up, come if you want, carry on if you need to be doing something else.”

The whole company is on their feet, one big 40 person circle. We don’t do the Scrummy standup here. We first intro any new employees, guests, interviewees, etc. Then on to things people need help on that they’re having a hard time solving within their team. Then lastly the “interestings”, stuff like “I made a thing in our tool set that’ll make doing stuff easier”, or “Don’t park your bike on Market Street tomorrow.”

The format is all about being relevant to [most] people who are attending. This is very different from a status meeting – problems get attention and knowledge gets disseminated. I love this stand-up.

Unfortunately, Pivots sometimes go off-site, where there isn’t stand-up Nirvana. In one case, the client was large enough that a handful of us Pivots were at the same place, distributed across several teams. As Pivots do, we created a hybrid of the status stand-up and our company stand-up. Every morning, we’d form a circle, and every morning the circle would be absent of client developers. I didn’t think much of it until I started to realize that stuff we talked about and addressed proactively in our stand-up was biting our client’s developers and they were getting placed in situations where they could only react.

As had been done before my arrival, I invited the client developers to join our stand up in the morning. To make the time easy to remember, and to help propagate the awareness of the event each morning, I obtained a cow bell for our use. Just like being at our HQ, I rang that bell when we gathered for stand-up. For three weeks, no one came.

No one really even acknowledged the sound of the bell. We joked that it only added to our cult-like appearance of standing in a circle. Then one day, I was running late, and missed breakfast, and as it was time for stand-up another Pivot told me he had just over-heard some people talking about the bell… JOY!!!!… using the word “obnoxious”… SADNESS, and he implied that it would be wise to have the ringing stop.

While it may be true that the bell has laid silent, and that it may have been foolhardy to assume what works in one place will work in another, I am not so certain it was a failure. As I said before, the purpose of the bell was to raise awareness, and to call it “obnoxious” is to certainly be aware. If it were just me, I might have continued to ring on. I think the better idea would be to make the stand-up itself be the thing that draws attention, “Where is everyone?”, “Oh they’re all at stand-up, didn’t you know?”

Trust me, I know.

Agile Pyramids

Will Read

Sunday, January 10, 2010

I recently returned from a trip to Egypt with Pivotal’s own Lara Owen. Like all good tourists, we went and saw the Pyramids of Giza. Like far fewer tourists, we also went to Saqqara to see the Step Pyramid and then on to Dashur, home of the Bent Pyramid and the Red Pyramid.

The Step Pyramid in Saqqara

In the 3rd Dynasty, the Step Pyramid is constructed under the rule of Djoser. The pyramid has entered the market. By the 4th Dynasty, under the rule of Snofru, six steps are no longer enough, users want seven steps and smooth sides.

The Bent Pyramid in Dashur

In an attempt to meet these new market demands, the Bent Pyramid construction begins. Half way through, they realize they made a mistake, and adapt their plan accordingly by changing the angle down from 54° to 45°. The next attempt, still within Snofru’s lifetime, becomes the gold standard of pyramids and is known as the Red Pyramid. With it’s consistent sloping smooth sides and added height, this pyramid was fit for any king.

The Red Pyramid in Dashur

What I thought about, as you might have guessed by now, was the methodology used to construct each of these pyramids. In the case of the Step Pyramid form the 3rd Dynasty, it would be easy to see a king proclaim, “I want this kind of pyramid and I want it ready by the time I die.” And he’ll get something twenty years later that resembles what he wanted twenty years ago.

Snofru had a different plan. He was going to shake up the way people think about royal tombs. He was going to do something no one else had done. This man of foresight said to his people, “We will release early, and we will release often. We will have meetings along the way to reflect on how we have progressed, and we will then plan ahead only as far as is practical, adjusting as we go. Most importantly, we will trust each other such that mistakes can be made without causing great harm to the project.” It was with this spirit that Snofru began work on the Bent Pyramid.

He didn’t know what he was doing, there was no model to copy, no patterns to solve this problem. So he guessed 54°. And they built, and they talked and said “Hey Snofru, this looks great, but it won’t be stable if we continue at this angle.” To which Snofru probably replied, “I will trust your expertise here, can we make the angle less steep and see how that works out?” So 45° it was.

When the finished, they stood back and looked at the work they had done. It was taller, and it did have smooth sides, but it wasn’t quite right. Snofru, being a wise king, knew that this was a great success.

A taller pyramid could indeed be built.
45° was a sustainable angle
He was still drawing breath and now had the knowledge to fully realize his goal.

Snofru still had plenty of time on his hands, and because he released early instead of letting construction drag on, he had new insight from the retrospective that he wouldn’t possess otherwise. So he built the Red Pyramid with complete success.

Snofru was, in my opinion, the first adopter of Agile principles. His “employees” trusted him enough to be able to push back when the plan needed revising. He trusted them right back not to yank his chain about things being too steep. He made his mistakes up front, which taught him lessons about his domain, and it enabled him to be successful in the long run.