Developer Experience (#devexp) is an aspirational movement that seeks to apply the techniques of User Experience (UX) professionals to the tools and services that we offer to developers. Developer Experience can be boiled down to 4 main ideas.

1. Apply UX techniques to developer-facing products.

Usability testing by watching people try to use your products without interfering so that you can get a realistic understanding of how people will actually respond. Some companies set up usability labs or run hackathons in order to get this kind of data.

2. Focus on the '5 minute Out Of Box experience'

The idea here is that if you provide a library, developers should be able to go from downloading to "Hello World" in 5 minutes. You should test this with a stopwatch or even a screencast to prove this is possible. Ideally they should then be able to take the code from this 5 minute experience and evolve it as their requirements grow in sophistication without having to start over. Making a library that supports the same user from unsure novice to sophisticated expert is hard but pays off in terms of increased adoption and fewer questions on the mailing list.

3. Use convention over configuration

This was most clearly stated by the Ruby On Rails community but is rooted in a simple insight. When someone first starts using your API or library they have the least knowledge so that's the worst time to ask them to make lots of complicated decisions with far-reaching implications. This is why you, the developer of the library or API, should make the initial decisions for them by establishing conventions that can be overridden with configuration options.

4. Try to "design away" common problems rather than documenting workarounds

For instance if your users struggle with getting OAuth working then create abstractions that handle it for them rather than documenting the 6 most common problems or writing up the 'simple 12 step process' for getting it working.

This is inspired by Don Norman's work on perceived affordances which says that things should be designed in ways that immediately suggest how you should use them. If you walk up to a door it should be obvious without reading any signs, whether you should pull, push or slide the door to open it. If the door needs to be documented with a sign then it was badly designed.

This theory of affordances applies just as well to developer tools and APIs. They should be designed to have affordances that encourage correct usage rather than documented to make up for deficiencies in usability.

The phrase (developer experience) and the hashtag (#devexp) comes from Michael Mahemoff but it's not a new idea. Its roots are in ideas and practices such as:

It's a set of ideas we would like to see more people, projects and companies adopt. We don't claim to be paragons and we're looking to learn from other people's examples.

That's why we've set up http://developerexperience.org/We hope to use it to point to examples of great developer experiences as well as aggregating relevant tweets using the #devexp hashtag.

Please join us. You can start by using the tag "devexp" whenever and whereever you write about developer experience. Over time this will help us build up a body of knowledge that will do for developers what UX has done for users.Add comments on Buzz

I was taking a look at my PeerIndex profile when I got the above screen. I was surprised since the button I clicked said "sign in with Twitter" and didn't mention anything about updating my data. I did a little digging and it seems that I'm not the only one who has this reaction.

In my case it was especially ironic since one of the things that I've been trying to do with the Buzz APIs is encourage developers to ask for the minimum set of permissions that they need.

The idea is that an app which is just going to use its access to your account to gather metrics shouldn't also be able to post messages on your behalf. That's why we expose 3 different scopes. These are read-only, read-write and a special scope for photos because those tend to be especially sensitive.

However developers will often just ask for the maximum set of scopes in order to give themselves the freedom to implement new features later on without having to ask the user to re-authorise them. They do this because it's easier for them and because they believe it results in a better user experience since the user isn't constantly being asked to give permission.

Unfortunately what many developers don't notice are the users who get to the authorisation screen and then close the tab because they don't understand why your app needs write-access to their account. The point is that asking for overly broad permissions, just like the password anti-pattern, repels users.

The tragedy is that all parties are trying to create the best possible user and developer experience (by avoiding complicating the user interfaces with lots of options and removing the need to constantly ask the user for new permissions) but the end result is bad for all concerned.

We've made a new release of the Universal Feed Parser. The new version is 5.0. It fixes dozens of bugs and adds backwards-compatible support for Python 3.

Over the last 5 years since the last release we've worked our way through lots of obscure corner cases in specifications like Atom, RSS 2.0, and RDF so that you don't have to. If you're writing anything in Python that parses any kind of feed then you should definitely be using this.

TL;DRIll-informed proponents of Software Craftsmanship tend to make the following mistakes:

they don't read anything except the manifesto and a smattering of blog posts.

they overlook books like Software Craftsmanship, Apprenticeship Patterns (which has dozens of references in the appendix looking at the nature of expertise and the mechanisms for the acquisition, transfer and enhancement of skill ) and The Craftsman.

they don't define terms like craft or art so they end up thinking Software Craftsmanship is some code-obsessed mishmash of martial arts and carpentry or plumbing.

they focus on how Software Craftsmanship can benefit masters rather than apprentices.

they think that signing the manifesto is the most important part of becoming a software craftsman.

Sadly Dan's blog post makes the same mistakes. Dan could provide some really valuable insights if he'd take the time to do some background reading.

My fellow ex-Thoughtworker, Dan North, recently wrote a blog post entitled Programming Is Not A Craft. I knew he'd been working on this and I was looking forward to reading a nuanced critique by someone with a long history in the Agile movement. I assumed that Dan would invest time in background reading and bring valuable new insights to the discussion. I was disappointed. He manages to write a long article in which he cites precisely one source. Unfortunately that's an Infoq page about Eric Meijer. His post ends up criticising a straw man version of the Software Craftsmanship manifesto by never quoting or linking to it.

If the manifesto was the only artefact we had then many of his points would be valid. Manifestos tend to skim over lots of complicated issues precisely because they are manifestos and are written to excite rather than explain. We have books, conferences and mailing lists for people who want to ask awkward questions about the details. Unfortunately some of the people who signed the manifesto or who are writing or presenting about Software Craftsmanship appear to have only read the manifesto. I wish some of these people would at least read the Wikipedia page. Or visit one of the companies that base themselves on the Software Craftsmanship model such as Obtiva, 8th Light or Eden Software. In an ideal world people would read McBreen's, admittedly flawed, book or Apprenticeship Patterns (also available online) or even Richard Sennett's The Craftsman. However in the real world people who like the notion of being a blacksmith or have seen too many Japanese martial arts films latch on to the perceived glamour of the manifesto and see it as a way to be associated with those ideas without ever doing the hard work of understanding them.

So as I read Dan's piece I was increasingly baffled. He appeared to be writing a parody of the worst aspects of the software craftsmanship movement. His article makes many of the mistakes that nuanced critics like Ravi Mohan, David Harvey and John Daniels have accused the Software Craftsmanship movement of making.

When it comes to the tricky problem of defining craft, Dave Hoover and I wrote "The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book. They are often circular (with craft being defined in terms of the skill a craftsman possesses, a craftsman being defined as someone who exhibits craftsmanship, and craftsmanship being defined as the quality that binds together the craftsmen working in the craft tradition), seldom grounded in the history of the guild system in specific countries, and often generalized to describe anything that is skillfully constructed. In short, these definitions fail to exclude anything and so include everything."

If you still want a definition then I recommend the one from Wikipedia: "a craft is a branch of a profession that requires some particular kind of skilled work. In historical sense, particularly as pertinient to the Medieval history and earlier the term is usually applied towards people in small-scale production of goods."

Dan also makes several allusions to plumbing, martial arts and silversmiths. However this reasoning by analogy obscures his points so much that when he starts conflating art and craft it passes unnoticed. He transitions smoothly from discussing his wife's artistry to talking about programmers moving information around rather than crafting software to talking about cathedrals that you don't realise that he's begun using the words "art" and "craft" interchangeably. Although the phrase "art of plumbing" in the line "What I don’t want, however, is a prima donna plumber who insists on talking about the elegance, beauty or art of plumbing, or who insists that I appreciate the aesthetic beauty of his joinery" was a clue.

I'd be the first to point out there's a tension in our industry between art and craft. We even wrote up a pattern about finding ways for dealing with that tension. It starts out with a quote from Richard Stallman: "Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty." Of course if you conflate the two things then Software Craftsmanship must seem like mere self-indulgence at the customer's expense. Consequently you can make the argument that programming is not a craft if you've effectively redefined craft to mean a focus on gold-plating or aesthetic concerns rather than utility.

I'd usually ignore a blog post as muddled as this except that Dan then proposed a rather worrying set of solutions to the current state of Software Craftsmanship. He suggests creating a new manifesto which is "feisty, opinionated, brash" as well as a Software Craftsmanship Council that would provide accreditation. This would be bringing back exactly the kind of restraint of trade that helped kill off the guild system in Western Europe. It's precisely the kind of closed shop that would drive a wedge between developers and everybody else who plays a role in getting useful software into the hands of real people.

Guilds may have been a necessary evil in medieval Europe but Software Craftsmanship is not about bringing them back. The Software Craftsmanship movement is at least partly about finding ways to include more people in software development. We focus heavily on ideas like apprenticeship, sharing knowledge and deliberate practice rather than on ways to enrich a small coterie of self-proclaimed 'masters'.

The funny thing is that I agree with many of Dan's points about the value of skill, the relative youth of our craft and the importance of focussing on delivering value to our customers. There's just a lot more to the Software Craftsmanship movement than you'll get from skimming the manifesto and I hope that once Dan's taken a look at the rest he'll write something that lives up to my expectations of him.

In the meantime, perhaps we should add a Further Reading section to the Manifesto's website to help reduce this kind of confusion?

I've recently started reading Only The Paranoid Survive by Andrew Grove. It's fascinating in many ways.

"Sooner or later, something fundamental in your business world will change." p1

p29

"Then there is a growing dissonance between what your company thinks it is doing and what is actually happening inside the bowels of the organization. Such misalignment between corporate statements and operational actions hints at more than the normal chaos you have learned to live with." p34

"There will be a growing ferocity, determination and seriousness surrounding the views the various participants hold. People will dig in. These divergent views will be held equally strongly, almost like religious tenets. In a workplace that used to function collegially and constructively, holy wars will erupt, pitting coworkers against coworkers, long-term friends against long-term friends." p35

"when a strategic inflection point sweeps through the industry, the more successful a participant was in the old industry structure, the more threatened it is by change and the more reluctant it is to adapt to it." p50

"The first mover and only the first mover, the company that acts while the others dither, has a true opportunity to gain time over its competitors--and time advantage, in this business, is the surest way to gain market share.

Conversely, people who try to fight the wave of a new technology lose in spite of their best efforts because they waste valuable time." p51-52

"While Jobs was burning the midnight oil inside Next, in the outside world something changed." p58

"It was as if Steve Jobs and his company had gone into a time capsule when they started Next. They worked hard for years, competing against what they thought was the competition, but by the time they emerged, the competition turned out to be something completely different and much more powerful." p59

"the person who is the star of a previous era is often the last one to adapt to change, the last one to yield to the logic of a strategic inflection point and tends to fall harder than most." p68

"Most strategic inflection points, instead of coming in with a band, approach on little cat feet. They often are not clear until you can look at the events in retrospect." p107

"if you had just one bullet in a figurative pistol, whom among your many competitors would you save it for? Asked point-blank, this question usually provokes a visceral response and I find that people can normally give an answer without much hesitation. when the answer to this question stops being as crystal clear as it used to be and some of your people direct the silver bullet to competitors who didn't merit this kind of attention previously, it's time to sit up and pay attention." p107

"The Cassandras in your organization are a consistently helpful element in recognizing strategic inflection points. As you might remember, Cassandra was the priestess who foretold the fall of Troy. Likewise there are people who are quick to recognize impending change and cry out an early warning." p108

"Classify the time you spend listening to them as an investment in learning what goes on at the distant periphery of your business, whether you think of distances in geographical or technological terms. Think of it this way: when sprint comes, snow melts at the periphery, because that's where it's most exposed." p110

"It got there by the autonomous actions of the finance and production planning people, who sat around painstakingly allocating wafer production capacity month by month, moving silicon wafers from products where they seemed wasteful--memories were the prime example of this--to other products which seemed to generate better margins, such as microprocessors. These people didn't have the authority to get us out of memories but they had the authority to fine-tune the production allocation process by lots of little steps." p110

"Peter Drucker quotes a definition of an entrepreneur as someone who moves resources from areas of lower productivity and yield to areas of higher productivity and yield." p110

"you can't judge the significance of strategic inflection points by the quality of the first version" p113

"you must discipline yourself to think things through and separate the quality of the early versions from the longer-term potential and significance of a new product or technology." p114

"It takes courage to enter into a debate you may lose, in which weaknesses in your knowledge may be exposed and in which you may draw the disapproval of your coworkers for taking an unpopular viewpoint." p115

"Don't sit on the sidelines waiting for the senior people to make a decision so that later on you can criticize them over a beer" p115

"The point is, strategic inflections are rarely clear. Well-informed and well-intentioned people will look at the same picture and assign dramatically different interpretations to it. So it is extraordinarily important to bring the intellectual power of all relevant parties to this sharpening process." p116

"Altogether too often, people substitute opinions for facts and emotions for analysis." p116

"But data are about the past, and strategic inflection points are about the future. By the time the data showed that the Japanese memory producers were becoming a major factor, we were in the middle of a fight for our survival." p117

"Constructively debating tough issues and getting somewhere is only possible when people can speak their minds without fear of punishment." p117

"The most important role of managers is to create an environment in which people are passionately dedicated to winning in the marketplace. Fear plays a major role in creating and maintaining such passion. Fear of competition, fear of bankruptcy, fear of being wrong and fear of losing can all be powerful motivators." p117

"Simply put, fear can be the opposite of complacency. Complacency often afflicts precisely those who have been the most successful. It is often found in companies that have honed the sort of skills that are perfect for their environment. But when their environment changes these companies may be the slowest to respond properly." p118

"It takes many years of consistent conduct to eliminate fear of punishment as an inhibitor of strategic discussion. It takes only one incident to introduce it. News of this incident will spread through the organisation like wildfire and shut everyone up.

Once an environment of fear takes over, it will lead to paralysis throughout the organization and cut of the flow of bad news from the periphery." p119

"From our inception on, we at Intel have worked very hard to break down the walls between those who possess knowledge power and those who possess organization power." p120

"A manager in a business that's undergoing a strategic inflection point is likely to experience a variation of the well-known stages of what individuals go through when dealing with a serious loss." p124

"Denial is prevalent in the early stages of almost every example of a strategic inflection point I can think of." p124

"Good leaders are also subject to the same emotional wiggling. They, however, eventually emerge to the acceptance and action phases. Lesser leaders are not capable of that and they are often removed. Then they are replaced by individuals who are not necessarily more capable but who do not have the emotional investment in the previous strategy." p127

"The replacement of corporate heads is far more motivated by the need to bring in someone who is not invested in the past than to get somebody who is a better manager or a better leader in other ways." p127

"As we begin to respond, maybe too little too late, we face another emotional hurdle: to admit to ourselves consciously and explicitly the magnitude of the problem we are struggling with Even as our actions begin to reflect the process of adjusting to the new environment, we still struggle with the task of describing them in clear words." p128

"I have seen many companies fall into the trap of saying one thing and doing another while they are in the midst of coping with a strategic inflection. I call this divergence between actions and statements strategic dissonance. It is one of the surest indications that a company is struggling with a strategic inflection point." p128

"Occasionally when I stand in front of such a group and field questions, I find it awkward to attempt to defend the position of corporation in the face of some specific questions and comments that come from people who are wise to their world and their environment. Often these questions come in the form of follow-up questions after I have been asked about our specific strategy regarding a particular product, customer or technology." p129

"Such questions usually represent sharp probing for the true intent behind the general answer I've just given." p129

"Strategic dissonance is so much an automatic reaction to a strategic inflection point that probing for it is perhaps the best test of one." p129

"While this dissonance between what the company does and what management says is understandable, it accompanies a terribly unproductive and distressing phase. The growing discomfort associated with strategic dissonance creates confusion and uncertainty" p129

"To make it through the valley of death successfully, your first task is to form a mental image of what the company should look like when you get to the other side. This image not only needs to be clear enough for you to visualise but it also has to be crisp enough so you can communicate it simply to your tired, demoralised and confused staff." p140

"You are trying to define what the company will be, yet that can only be done if you also undertake to define what the company will not be." p140

"the transformation implicit in surviving a strategic inflection point involves changing members of management in one way or another" p143

"The implication was that either the people in the room needed to change their areas of knowledge and expertise or the people themselves needed to be changed. I remember looking around the room, wondering who might remain and who might not." p143

"Admitting that you need to learn something new is always difficult. It is even harder if you are a senior manager who is accustomed to the automatic deference which people accord you owing to your position. But if you don't fight it, that very deference may become a wall that isolates you from learning new things." p145

"While strategic plans are abstract and are usually couched in language that has no concrete meaning except to the company's management, strategic actions matter because they immediately affect people's lives. They change people's work" p147

"Simply put, in times of change, managers almost always know which direction they should go in, but usually act too late and do too little." p149

"When you drive in the fog, it is a lot easier to drive fast if you're chasing the taillights of the car ahead of you. The danger with a 'taillight' strategy is that, once you catch up and pass, you will find yourself without a set of taillights to follow--and without the confidence and competence in setting your own course in a new direction." p149

"In recent years, we at Intel decided that we have a tremendous opportunity to exploit the personal computer as a universal information appliance." p 150

"it is very hard to lead an organization out of the valley of death without a clear and simple strategic direction. After all, getting there sapped the energy of your organization; it demoralised your employees and often set them against one another. Demoralized organizations are unlikely to be able to deal with multiple objectives in their actions. It will be hard enough to deal lead them out with a single one." p151

"If you're wrong, you will die. But most companies don't die because they are wrong; most die because they don't commit themselves. They fritter away their momentum and their valuable resources while attempting to make a decision. The greatest danger is in standing still." p152

"Clarity of direction, which includes describing what we are going after as well as describing what we will not be going after, is exceedingly important at the late stage of a strategic transformation." p 153

"When you have to reach large numbers of people, you can't possibly overcommunicate and overclarify" p155

"Your new thoughts and new arguments will take awhile to sink in. But you will find that repetition sharpens your articulation of the new direction and makes it increasingly clear to your employees. So speak and answer questions as often as possible; while it may seem like like you're repeating yourself, in reality you will be reinforcing a strategic message." p155

"If your employees don't have an opportunity to test your thinking in live sessions or electronically, your message will seem like so much hot air.

Resist the temptation to do what's easy here. Communicating strategic change in an interactive, exposed fashion is not easy. But it is absolutely necessary." p157

"Simply put, you can't change a company without changing its management. I'm not saying they have to pack up their desks and be replaced. I'm saying that they themselves, every one of them, needs to change to be more in tune with the mandates of the new environment." p 157

"They need to adapt. If they can't or won't, however they will need to be replaced with others who are more in tune with the new world the company is heading to." p157

"It seems that companies that successfully navigate through strategic inflection points have a good dialectic between bottom-up and top-down actions." p159

"The Internet fosters the emergence of a third class of use: applications and data that are stored at some other computer someplace, prepared and owned by unrelated individuals or organisations, that anyone can access through this pervasive set of connections" p179

"All this suggests that the Internet is not a strategic inflection point for Intel. But while the classic signs suggest it isn't, the totality of all the changes is so overwhelming that deep down I think it is" p181

"Packaging Internet activities separately and elevating them on a par with our other three objectives is a way to communicate their significance to the entire company." p183

"It is likely that the Internet appliance is a case of turning the clock backward, given that the trend over the last twenty to thirty years has consisted of pulling down intelligence from big computers to little ones. I don't believe the Internet is about to reverse this trend. But then again, my genes were formed by those same twenty or thirty years. And I'm likely to be the last one to know." p184

That kind of faceted classification solves the navigational problem but it also removes one of the main obstacles preventing me from writing more book reviews. I'm most interested in a book whilst reading it but I don't write a review until afterwards. That's the point I most wish I'd kept ongoing notes but care the least about going back and creating the notes.

So based on Brown's example I'm going to start capturing notes about the books I'm currently reading using this blog. I don't have the structural flexibility that Brown's use of Expression Engine affords (nor the inclination to set it up) so I'm just going to start a post when a book captures my interest. I'll update it with photos and quotes as time passes.

A group of us entered a team in a photography contest held at the National Portrait Gallery. Improbably enough one of our photos (not the one below) won and we got to see it projected onto the walls of the gallery.

I attended OpenTech. I think I may be one of the few people who has managed to attend every single OpenTech. Even back when it wasn't called OpenTech.

I went back to the US in the autumn and got to meet a lot of the ex-Thoughtworks crowd who are now at DRW Trading.

Straight after that the Google Developer Days took me across Europe including a walk through Red Square at night.

I got back from that just in time to help run the world's hardest raffle at XPDay.

This was followed by the chance to see GoogleGogol Bordello live at the Kentish Town Forum.

As part of the translation process I wrote a new foreword and last week I got to see it in print for the first time. Since I can't even guess at the meaning of Kanji symbols I had to infer the meaning from memory. Seeing my own words in a language I couldn't understand generates the strangest feeling of alienation.

I thought I'd share something of that feeling. You can read the English and Japanese versions of the foreword below. Hopefully those of you who can read both languages will better appreciate the craft of translation after seeing both versions.

The craft of translationThis book you're holding in your hand is about what it takes to do skilled work. In the months we've worked with Yoshiki Shibata I've come to appreciate the skill involved in translating a book and how lucky we are to have a translator who shares so many of our values. Translation is not a matter of mechanically converting words any more than a programmer's job consists of mindlessly converting requirements into code. In both disciplines we must add something of ourselves in order to transmute the raw materials into something that reflects our skill and our spirit.

One of the lessons I've learned in the five years since we started working on Apprenticeship Patterns is that it's really easy to assume that other people share a lot of your obscure and tacit knowledge. Our original version of the book is full of little bits of tacit knowledge that we've extracted from the experiences of our interviewees and Shibata-san has helped us make that material clearer. In some places he has gone beyond mere translation and helped us see our words in new ways.

I hope that this book will inspire you to become part of the Software Craftsmanship community. I hope that it will inspire you to improve your skills and I hope that it will guide [you] on to the path of apprenticeship. After all that's the long road we're all walking.

In August I'm going to be on a panel at the BlogTalk conference where we shall be discussing the differences between social and conversational networks. This blog post is an attempt to clarify my thinking and get some definitions out there.

We all have a rough idea of what makes a social network. For me the important elements are:

Symmetric relationships

Expressing connections with people you already know

Messages default to private

A strong sense of who can see your data and in what context

On the other hand a conversational network is primarily based upon:

Asymmetric relationships

Following people you find interesting even if you don't know them

Messages default to public

Your data ends up in various different contexts and may be aggregated/remixed/reused all over the web.

This isn't a dichotomy but a spectrum. Services occupy points along this spectrum and often move across it as they add or remove features over time.

Neither extreme is better than the other and individual users may need to use a service in ways that defy the expectations of the service's creators. This leads to the situation where a conversational network like Twitter has protected accounts and a social network like Facebook lets you publish status updates that the whole world can see.

This is just a model, a way of looking at the world, but it has interesting implications.

For example the model shows me that I use Flickr more than PicasaWeb or Facebook photos because I mostly desire a conversational photo-sharing experience. I want people to aggregate/reuse/remix my photos so I use a Creative Commons license and join interesting groups that juxtapose my photos with other people's work or encourage blogs (like Global Nerdy or Londonist or martinfowler.com) to embed them.

Another interesting implication is that whilst most of the interesting people and most of the web's creativity is at the conversational end of the spectrum, most of the people are at the social end of the spectrum. This intriguing contrast was first raised by my colleague Paul Adams. He pointed out that the vast majority of people don't want to be on public display and this 1% rule leads to services where only a few create content which a lot more share/curate and the vast majority consume.

In fact this isn't a weakness of the model but a strength because that's the world we live in.