Jessi Hempel’s The second coming of Facebook is a very interesting profile of the company and where it’s headed. There’s one paragraph in particular that has stuck with me for the past few days:

At Facebook developers choose the projects they want to work on, and product groups compete to woo them. Managers sent out reports highlighting the product teams that were doing a good job. Pretty quickly teams realized that if they wanted to get praised in the weekly memo, they needed to start recruiting mobile developers.

My first thought was that this is a great idea. If you want to get something done at Facebook, your idea has to be interesting and challenging enough to convince developers to work on it, otherwise it just won’t happen. I’m sure this weeds out a lot of ill-conceived project ideas.

But there’s a problem with this approach. If Product Managers have to convince developers to work on their projects, they are going to pitch ideas that have a big chance of being interesting to… developers. Not to Facebook users. So there’s a danger that the product features being pushed out are wild and challenging and extremely interesting, but don’t meet user needs particularly well.

In the example cited in the article, an internal weekly memo effectively changed the company’s entire roadmap by shifting attention to mobile. Not that shifting to mobile is a bad thing, but too much focus on things like who gets praised in an email has the potential to seriously derail a company.

Still, the idea is really appealing: making Product Managers effectively vie for developer attention ensures that the PMs do their homework so that they can sell and defend their ideas to the company and to customers. That’s a worthy cause. It would be great to make some form of user validation part of what happens before projects are pitched, though. I guess I just remain weary of the prevailing myth that we are like our users.

I know I just wrote about coffee, but this one is too good not to link to. In Coffee and the Art of Customer Happiness Mathias Meyer writes about the similarities between making coffee and developing software:

Baristas are geeks, just like we are. They love talking about the latest toys, about which espresso machine is better than the other, they compare paper filters with cloth, and they take detailed notes on the different aromas of coffee when they’re cupping it.

The craft of coffee making is quite fascinating, both from the perspective of precision and customer care.

Mathias discusses familiar topics like metrics, continuous delivery, and custom vs. off-the-shelf software, and what the art of coffee can teach us about each. Great article.

(link via @bb)

Joel Spolsky wrote a great post on some of the hidden costs of software development. From Software Inventory:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It’s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.

He goes on to propose an alternative to Backlog Grooming — one of the central tenets of Agile development:

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

His proposed solution is quite radical from an Agile perspective, and I’m not sure how it would work on large redesign/replatform projects, but it’s certainly worth considering.

Matt Simmons wrote a great post on designing elegant solutions for when users inevitably make mistakes on your system. In Engineering Infrastructures For Humans he uses the example of ash trays in airplanes to make his main point:

You don’t engineer your systems with the belief that none of your computers will ever break. That’s insane; you KNOW they’re going to break. So don’t assume that your users will never break the rules. Build in graceful failure as often as possible, whether you’re designing a user interface or a security policy.

The ash tray story is really interesting, so be sure to click through to his post.

Jeff Atwood starts his article This Is All Your App Is: a Collection of Tiny Details as a post about cat feeders, but stick with it. It’s gold:

Getting the details right is the difference between something that delights, and something customers tolerate.

Your software, your product, is nothing more than a collection of tiny details. If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis ”“ you’re not creating great software. Someone else is. I hope for your sake they aren’t your competitor.

Kyle Baxter in Programming Literacy:

I love the trend toward trying to teach people who aren’t going to necessarily develop software for their occupation how to think like programmers do. The sort of things you learn ”” breaking a larger problem down into smaller problems, thinking very precisely and step-by-step, thinking about things as a system ”” are skills that are widely applicable and useful. It teaches you how to analyze a problem, how to move from “we want this accomplished” to “to accomplish this, we are going to break it down into these pieces,” and it teaches you how to see how systems work. Both are incredibly powerful.

Baxter makes a good point that’s often missed in the “Should Designers learn to code?” debate. In many cases, learning to code is not about being able to build products. It’s about learning how to think better. And that’s a skill that we all need.

Fred Wilson on what’s needed to build product in the early stages of a startup, in The Management Team While Building Product:

Building product is not about having a large team to manage. It is about having a small team with the right people on it. You need product, design, and software engineering skills on the team. And you need to be focused, committed, and driven. Management at this point is all about small team dynamics; everyone on board, working together, and getting stuff done. Strong individual contributors are key in this stage. Management skills are not a requirement. In fact they may even be a hindrance.

Startup teams always have software engineering skills on board from the very beginning - as they should. But too often you see marketing and business development skills being added before you see product/design skills. This leads down a dangerous path that too often ends in a catastrophic lack of product/market fit.

How designers and engineers can play nice is a really great post by Jenna Bilotta. I nodded along enthusiastically to this point in particular:

Too often I observe my fellow designers rip into the aesthetics or interaction design of an early engineering prototype. When an engineer is met with critical feedback from a designer about issues they haven’t even begun to think about, it doesn’t encourage that engineer to include the designer in future reviews. This is how designers end up begging for massive changes the week before launch, and how we almost never get them.

One of the most difficult skills for a designer to learn is restraint during the early stages of implementation, when things aren’t perfect yet.

There are some great suggestions in the article - well worth reading.

I’ve written about Dhanji R. Prasanna excellent post on Google Wave and working at big companies before, but I wanted to come back to something he said that I just can’t get out of my head. In one section he talks about a topic I care about very much - what motivates people to do great work. I really like his perspective on the importance of incremental progress:

[As] a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria.

I like the analogy of these small wins as Deus Ex Machina:

[It means] “God out of the machine”; a seemingly inextricable problem is suddenly and abruptly solved with the contrived and unexpected intervention of some new event, character, ability, or object.

It’s so important for large teams to celebrate those wins with the people they work with every day - and to call out the “characters” responsible for accomplishing Deus Ex Machina. It is hard to get that right in large organizations because the invisibility of individual team members and the pressures to move on to The Next Thing aren’t naturally conducive to this type of behavior. But it’s possible if you work at it.

Whether you keep some champagne in a fridge, send out company-wide emails thanking people personally, or ring a bell every time code gets deployed (ok, that last one is lame, sorry), being in a large organization isn’t an excuse for acting like a faceless corporation.

John D. Cook writes some scary true words in Productivity and negative space:

People who fracture their time putting out fires seem more productive, or at least more responsive, than the people who block out time to think. It’s harder to notice someone not being frantic. Thinkers don’t fare well in environments that reward activity more than accomplishment.

This is such a huge problem in big corporations today. People who are running from meeting to meeting are perceived to be more productive than those who sit at their desks working all day[1]. And the problem is worse for programmers - very few managers understand what they do, so it’s hard for them to stomach days and days of solid coding without seeing something “tangible” (in their view).

It all comes back the difference between Makers and Managers, and how the Makers should be evaluated on completely different criteria than the Managers. Criteria that reward the quality of what they make, not the number of status updates they give.

(link via Graham Poulter)

---

1. I’m not saying that people who have a lot of meetings are necessarily less productive, just that those who are not in meetings are “out of sight, out of mind”, and therefore not seen as particularly productive.  â†©