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.  â†©

I was privileged to speak at Tech4Africa 2011 about a topic that I care about a great deal: how our environments and the way we work impact the quality of the software we produce. The talk came out of a question I keep asking myself over and over: why, despite our best efforts, do we still too often produce low quality software? Here’s the talk summary:

Why do we see so many web applications with inferior user experiences? Why do UX designers often get stuck being asked to “make the design pop a little more,” with no room or incentive to innovate? Why do some web developers feel demotivated and unable to break out of doing things the way they’ve always been done?

In this talk I explore some of the main causes of ineffective software development, and discuss practical recommendations on how to improve team structures and development processes to build high quality software that users care about, want to use, and that therefore makes more money for the business.

I discuss how designers and developers can work better together, how to ensure everyone gets input into the roadmap without it becoming chaos, and how to make sure that the business benefits are clearly articulated and communicated.

So here are the slides from my talk - I hope you find it useful. If you’d like to read more about this topic, you can check out a two-part series of articles that I wrote for Smashing Magazine.

I love the Automattic Creed that all their employees have to sign before they join the company:

I will never stop learning. I won’t just work on things that are assigned to me. I know ther’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything.

I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company.

I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

(h/t to @SwimGeek for the link)

This is going to sound like such a lame “management guru” thing to say, but it’s true: the cultural fit of the people you hire is more important than their past experience or absolute skill level. I’ve seen this time and time again. If I have a choice between hiring someone who is highly skilled in their work but doesn’t display humility and a genuine drive to learn more, and someone who knows enough to know that there is much to learn and they’re hungry to get there, I’ll choose the latter every time.

We recently went through an exercise to define our team values, and in many ways it’s similar to Automattic’s creed. I won’t bore you with the whole thing, but here are the main points. This is how we want other people to describe our team:

• We are zealots about quality
• We have autonomy to do what’s best for the product, its users, and our business
• We have a high fix:complain ratio
• We have a healthy work/life perspective
• We are empathetic to the core

The relationship between a healthy culture and doing great work is causal, not simply correlation. Good culture is the prerequisite for great work to happen, and actually causes it. Alan Cooper recently address this issue in a great article called The pipeline to your corporate soul:

If you want to improve the quality of your website, app, or software, you need to also improve the quality of your organization. You need to ferret out the people who play politics but don’t get things done. You need to squash bureaucracy that stops innovation with doubt and red tape. You need to eliminate the energy drains, systemic distortions, and toxic people that force others to act like corporate drones instead of like entrepreneurs with a vested interest in success.

If you put a bunch of talented, energetic, ambitious people together and make it easy for them to collaborate and do great things, they will. I haven’t seen a single example of great work preceding a clearly defined and healthy culture - even if it’s just an unspoken understanding between two startup founders. Spending time on getting your culture right is worth the effort.

Dhanji Prasanna wrote a great article about his experiences on the Google Wave team, and the difficulties of working in large development teams. He brings a particularly interesting perspective to UI engineering:

To say we should have been better prepared or organized is to miss the point - large teams starting on a new project are inherently dysfunctional. One common consequence of all this chaos is that experienced engineers seclude themselves to their area of expertise. At a company like Google, this generally means infrastructure or backend architecture. A major externality of this is that fresh grads, and junior engineers are shunted to the UI layer. I have seen this happen time and again in a number of organizations, and it is a critical, unrecognized problem.

UI is hard.

You need the same mix of experienced talent working in the UI as you do with traditional “serious” stuff. This is where Apple is simply ahead of everyone else - taking design seriously is not about having a dictator fuss over seams and pixels. It’s about giving it the same consideration that you give any other critical part of the system.

I’ve experienced this first-hand, and I’ve also seen what happens when backend developers are forced to do UI work (which can happen for a variety of reasons). I’ve heard developers say that they don’t like to do UI work because “it’s not real programming”. They prefer to focus on the real stuff, not this fluffy CSS/JavaScript thing.

Whether or not their perception is accurate is only one part of the discussion. What I want to point out is this: If you make backend developers do front-end work that they’re not passionate about (or worse, work they find embarrassing to do), they’re not going to be motivated to expand their knowledge and do a good job. That’s unfair to everyone and disastrous for the product.

It’s essential to have dedicated UI engineers in an organization so that everyone can focus on the technologies that they’re obsessed with.