Kent Beck is really a relationship consultant, or should that be counsellor? This is not a bad thing. Beck gave a keynote this morning here at Qcon and talked a bit about techie topics like frequent deployment (he claims that Flickr deploys every half an hour) and creating more tests more often, but the main focus of his talk is relationships within the development team and between the team and the business people (if they regard themselves as separate).

Beck says that the ubiquity of computing is changing the typical characteristics of a programmer. When only geeks had computers, programmers were inevitably geeky – and for whatever reason, that often meant something of a social misfit. Today everyone grows up with computers, which he says makes programming more accessible to non-geeks, who have better social skills.

Reflecting on this, I’m not quite convinced. Yes, everyone grows up with computers, but few have any inclination to understand how they work. A nation of car-drivers does not make a nation of engineers.

Still, that doesn’t affect his main point, which is that characteristics like trustworthiness, transparency, honesty, accountability, and the ability to get on well with others, are critical to successful development:

I focus on what developers can do to have better social skills and be better business partners.

In an aside on accountability, Beck makes a point about Windows and the “beginning of the end of the Microsoft monopoly.” He says that people are realising that they don’t have to put up with computers that are unreliable or require frequent restarts:

How many hours are spent worldwide waiting for Windows to restart, do the maths. Software needs to be effective and needs to work; increasingly there are alternatives.

Windows can work pretty well in the right circumstances; but it’s a fair point nonetheless. I recall the effort it took to set up a laptop recently. Microsoft’s fault, or third-party problems? Both; but the user doesn’t care whose fault it is, but only wants a better experience.

Incidentally, the team theme came up again when Peter Goodliffe spoke on good and bad application design. He observed that bad design is damaging to teams; uncertainty about what the code does or where new code should go stresses relationships, and working with a bad design damages morale. My reflection was that the team is primary, not the design. A bad team will never come up with a good design. A good team could still find itself working with a bad design though, so focus on design is never wasted.