I have been in the firing line recently for failing to
develop acceptable performance management targets for software developers. I
consult for a business that believes, strongly, in performance management –
setting Key Result Areas, Key Performance Indicators and performance targets
for all staff. We measure performance monthly. When staff members over-achieve
they are rewarded with a bonus. When they under-achieve we investigate to
determine why. Sometimes it is because they had inadequate resources, sometimes
it is because they didn’t have the skill and sometimes it is because they didn’t
have the will.
Top management expects software developers to write bug-free
code. Nevertheless we employ a tester to check. Testing is what is done in the
software development field – it is essential to product quality.
So the question I am being asked by management is why? Why
can’t developers be like everybody else in the organisation, excel at their
work and develop bug-free code?
So I did some research. On the Internet, where else?
Developers worldwide develop code with bugs. It’s
unavoidable. According to one site, if business managers think they can set
performance targets for developers like they do for everyone else in the
business, they are mistaken. And if there is an HR Manager out there who can
develop suitable targets for developers that enable the effective management of
their performance, he or she will be the next speaker on TED.com. And moreover,
will be sought after by Bill Gates, Tim Cook, Mark Zuckerberg and everyone else
who matters in the software development field.
I haven’t given up – not yet.
But I had some thoughts recently:
I am attending a course on the Internet called “Learning How
to Learn” with Barbara Oakley and her team from the University of California,
San Diego. I thought I knew nearly everything about learning – after all I
wrote a book on the subject in 1999 – but I enrolled because I thought there
might just be something new. And of course there was. I learned very early in
the course about the focused mind and the diffuse mind. The focused mind is
what we all use to do our jobs – even developers use the focused mind. The
diffuse mind is for something else. We use it for creativity and innovation,
for ‘understanding the whole’ and not just the parts that make it up. We
should, according to Barbara, use both but at different times.
So I did some diffuse thinking.
I thought back to my book on learning and how it evolved. I
remember writing for nights on end. But I remember more that I sent it to a
colleague for editing. My colleague, Howard Dean, held on to the hard copy
pages of my book for three months and then sent it back in a large envelope
which I opened and first I read his covering note.
Fortunately.
He wrote: “You have a natural story-telling ability, but……”
And he then went on to say there were a few corrections needed.
I looked at Page 1 and there were three or four red marks in
ball-point pen. I looked at Page 2 and saw the same. There were, I was to find,
red marks and writing on EVERY page. I was shocked. How could I have written
such drivel? But because of the comment on the cover note, I didn’t throw the whole lot in the
waste-paper basket. I took up the challenge and repaired all the ‘bugs’.
The book was eventually published and I won the Zimbabwean
Personnel Practitioner of the Year in 2000.
On the question of developers and bugs, my diffuse thinking continued
working. And I did some 'chunking'
Successful authors all have editors who find the ‘bugs’ in
their work. I know this because nearly every successful editor acknowledges the
help he or she received. Only after the ‘bugs’ have been found and repaired do
the books reach the market. Authors and Software Developers must have something
in common, methinks. The difference probably being that developing software is a
far more intricate and exacting task than writing a book, (or a blog like this).
How does one manage the performance of an author? Quite
simply by the number of books he or she sells. And perhaps that is how we
should manage the performance of a Software Developer? Well, not exactly the
same way, but on the successful or unsuccessful deployment of the software.
But like the author who ‘develops’ books with ‘bugs’, we
should expect the bugs in the original software and managers should not
penalize software developers for creating them. They should instead employ
Software Testers who excel at using their diffuse minds to make every attempt
to break the software before it reaches its market.
So software developers, like authors of books, rely on a
colleague, a partner – in the case of an author, the editor and in the case of
the software developer, the tester.
My problem is not over though: how do we manage the
performance of a software developer on a month by month basis? There has to be
a way.
No comments:
Post a Comment