Friday 29 July 2011

Implications of being post-PC

At last night's OSJam I gave a lightning talk about the implications of being post-PC.

Those implications were:
Identity: a post-PC device needs to know its owner's identity since it can't rely on obtaining that information from a PC. At the moment all the devices are building their own identity platforms but eventually they'll start to take advantage of existing identity systems like Webfinger and PGP.

Personalisation: a post-PC device can be uniquely personalised because it's not predicated on the idea that it will be a shared device. The classic example is the experience when you buy a Kindle from Amazon. It will be preconfigured with your name and the books you've already bought. It's a small step from there to a future where the moment I bought a device in a shop it would automatically know that it belonged to me.

Kindle personalisation

Cloud: post-PC devices tend to be heavily dependent on the cloud in order to store persistent state and to perform sophisticated processing. The definition of the cloud that this implies comes from Simon Meacham. He says that the cloud means treating the union of all those servers/networks/services as if they were one machine available to be used by everybody. In this vision the physical devices we own are merely portals to and caches for this metaphorical "one machine."

Mobility: if our data and services live in this cloud then all the devices I can log in to are equivalent. At this point the ability to take a device to the place I wish to use it (for instance the Kindle screen is supremely legible in bright sunlight unlike the screens of most mobile phones) and the fact a given device is ready-to-hand will trump all other considerations. Photographers have long had a saying "the best camera is the one you have with you" and the rest of the world will soon experience something similar.

Devices: new kinds of devices become possible, if not inevitable, in a post-PC future. Technology will migrate to the most convenient form and place in your life. That means computers, cameras and music players will start becoming features of watches, jewelry and clothing. That's partly because people actually like their watches, jewelry and clothing whilst they mostly tolerate their computers. The early examples of this are Nike+ and the increasing variety of smart watches. In fact several of the people attending OSJam were wearing the precursors of the smart watches of the future. Furthermore once people stop expecting technology to be delivered to them in a beige box it opens the doors to new innovators such as Arduino enthusiasts and the open source hardware community.

From OSJam 19 - Post-PC: gadgets of the now

Personal Area Networks: The logical culmination of this is the personal cloud or personal area network. This is not merely a network of devices that are physically close to one person. Instead it is a network of devices that are geographically distributed but which can connect to each other (via a variety of networks and protocols including the internet, wifi and bluetooth) and prove that they belong to the same person. The devices are tied together by the fact that they belong to a single person and therefore they can seamlessly share each other's functionality.

These are merely my guesses about what's likely to happen as a consequence of these post-PC devices. Ultimately Alan Kay is right: the only way to predict the future is to invent it.

Sunday 8 May 2011

What is Developer Experience?

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.

These techniques and ideas include:
  • Personas
  • Lo-fi prototyping and sketching
  • 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.
  • A wider range of techniques from UX research practitioners
  • GOMS

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.

Push Pull

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
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

Tuesday 29 March 2011

The irony and the tragedy of OAuth scopes

Overly broad permissions

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.

In the case of the Twitter API the problem seems to be that any HTTP POST API call is considered a write and so services like PeerIndex end up needing to ask for read-write access even though they're well-behaved.

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.

Add comments on Buzz

Thursday 27 January 2011

Release 5.0 of Universal Feed Parser for Python

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.

Our official announcement is here. Enjoy.

Add comments on Buzz

Thursday 13 January 2011

Software Craftsmanship: More than just a manifesto

Ill-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.

Firstly he doesn't define his terms. If you're going to say that X is not a Y you need to be very clear about what you mean by X and Y. When I refer to Software Craftsmanship I mean "a community of practice united and defined by overlapping values" and the book goes on to list many of these values.

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?

Add comments on Buzz

Wednesday 12 January 2011

Only The Paranoid Survive

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

Only the paranoid survive

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

Six Forces Diagram 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

Add comments on Buzz

Building my working library

If you've read my book, Apprenticeship Patterns, you'll know that I'm a big fan of both Twyla Tharp and Richard Sennett. Finding someone else who has read and liked works by both authors is a rare pleasure.

That's why I was so happy to find Mandy Brown's A Working Library. It's a blog plus an ongoing collection of notes on the books she's reading.

Brown's blog is structured in such a way that a book like Sennett's masterful The Craftsman becomes the spine for a series of posts: She then takes the idea even further so that when a post is really about 2 books it creates a page which references both of them. For instance here's a post which references both Tharp's The Creative Habit and Sennets's The Craftsman. Notice the way it appears in both the section on The Craftsman and in the section on The Creative Habit.

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.

Hopefully this will lead to more reviews of more books than I managed in 2010.

Add comments on Buzz