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