Customer Affinity

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

There are many aspects to customer affinity. The first one is just the interest in the business, its processes and rules. I've always been fascinated by domains I've worked in: health care, derivatives, payroll, leasing - are all examples of really interesting domain problems with a lot of complexity that has to be organized and understood. For me aspects of a project such as object-relational mapping, remote process communication - what I think of as the plumbing of enterprise systems, don't have that same interest.

It's important that a team has the plumbing working and under control, but I believe that the more energy goes into the business problem, the more effective at providing value a team will be. Which is a good reason to use frameworks that solve and simplify as much of the plumbing as possible.

Another aspect of customer affinity is the ability to collaborate with domain experts. I don't think that detailed knowledge of the domain is an important thing for programmers to have; useful yes, but not important. What's more critical than knowledge is the ability to collaborate with those that have the knowledge.

My high regard for customer affinity is one the main reasons why I'm such a fan of Extreme Programming and other agile methods. I found it very significant that when Kent Beck summarized XP to his agile peers at the snowbird workshop which coined 'agile', he chose to describe not the technical elements of XP, but his desire to change the nature of the customer/developer interaction.

I've often heard this relationship mis-characterized. In particular there is a belief in some quarters that the customer team just comes up with stories which they throw at the developers. This characterization is rather like the notion that requirements are just lying out there to be gathered. Either way that's not much of a collaboration. Instead developers need to work together with domain people to generate ideas with developers learning a lot about the business in the process.

One of Kent's suggested names for 'Agile' was conversational software development - the point being that it's a two way communication. This isn't something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features - often ones that aren't things that the customer originally thought of.

One of the things that frustrates me is how organizations often try to squelch customer affinity. It's not something people admit to doing, but it's a common consequence of other decisions. Organizational barriers can contribute to squelching - I've come across places where you have to get your manager to arrange with another manager just so you can have a conversation with someone on the business side. That hardly encourages you to get inside the workings of the business.

I've often heard it said that enterprise software is boring, just shuffling data around, that people of talent will do "real" software that requires fancy algorithms, hardware hacks, or plenty of math. I feel that this usually happens due to a lack of customer affinity. The real intellectual challenge of business software is figuring out what the real contribution of software can be to a business. You need both good technical and business knowledge to find that. Working closely with business people to develop this knowledge, and PleasingTheCustomer as you do it, is what makes enterprise software development fun - and motivation is the key to good and productive work.

There are plenty of bright and capable people who want to learn about the businesses they write software for. Too often organizations make it hard for them to do so. Until that changes, our profession will continue to under-deliver on our potential.