Tag: teams

For nearly 25 years, I have been writing some form of software code or another. For nearly twenty of those years I was paid to do it. When I started I was called a ‘programmer’. I don’t know exactly when everyone – including myself – started using the term ‘developer’ as a synonym for ‘programmer’, I do remember spending all 12+ years as a Java programmer being called a Java developer. But really I still just programmed – this time in Java.

Then along comes all these fancy shmancy process frameworks that talk of teams. One in particular – Scrum – boldly calls out the ‘development team’ as a cross-functional group who deliver an increment of a product at regular iterations.

Now as I help teams and organisations be more effective by applying Scrum (amongst other things), I am often asked who is in the Scrum development team. Typically I say:

Developers, testers and everyone who can carry out the required functions needed to sustainably deliver a working product increment

Often this response gets some push-back along with a sense a alienation – “But I’m a QA, I’m not a developer – am I in the development team?” or “I’m an Interaction Designer, am I in the development team?”.

My revelation

These questions left me puzzled and during one of my thinking sessions it dawned on me that:

Yes, all those people are in the development team and they are all expected to be developers. The problem is not them. The cause of the confusion is not their function, it is the hijacking of the term ‘developer’ and making it mean the same as ‘programmer’.

Being developer is not a function, it is an attitude.

Programmer, tester, UX, cryptologist, devops, CM engineer and other similar things are specialist functions. You can have a group full of these in your ‘cross functional team’ without them being a development team. Likewise, you can have them all in a group and they can simultaneously be developers with certain functional expertise.

About programmers

Programmers like to program. Actually let me rephrase that. Programmers love to program. It is our passion. We love to play with code for no other reason that it makes us happy and it fuels our curiosity.

In programming, we push the boundaries of our knowledge, gain skills and explore a world where we make things – sometimes pretty cool things – happen. Programmers are curious people – not about everything – but certainly about how computers tick and how we can make them tick differently. I say again – it is our passion. The thing that makes our eyes light up in an otherwise uninteresting conversation.

As a programmer, I don’t really care whether what I wrote is marketable or whether it is usable by anyone but me. Even broken code is interesting to a programmer and as for tests – screw them – I know how this sucker is put together and where it breaks and how to avoid it. Also, I don’t care if it solves anyone’s problem other than mine – even if my problem was “I was bored”.

Programmers are not lone wolves or billy-no-mates. We have friends, not many and typically they are other programmers. Programmers are collaborative even if sometimes a little competitive.  Our focus is inherently narrow, oh but what focus. We think deeply about the problem and delight in reaching a state of elegance and great technical design that makes our every future move in the code sublime.

Now, please don’t misunderstand me. Programmers are vitally important. The World is deeply computerised and will continue to be. It needs people who are curious about computers and passionate about making them do things. The World also needs at least some of those programmers to apply their skill to developing solutions for the challenges that face us all.

Expanding this further, let me say that functional specialists are vitally important. That is where expertise is created and boundaries of the possible are pushed out further and further. Functional specialists are driven by the curiosity and fulfillment that their specialisation provides.

There is no shame in wanting to remain only a programmer or any functional specialist. Personally I would be delighted to simply code stuff in my study all day and all night and never attend a single meeting about any damn thing. In fact I would like to not talk to anyone and have no one talk to me. My brain gets shafted with all the things I have to hold in it as a developer AND as a programmer and I would be quite content not having my brain shafted. Luckily the stuff I know as a programmer is pretty much instinctive now, but nevertheless, being a developer is still hard work.

Whilst there is no shame in choosing to be only a programmer, there is pain and suffering in privately and silently choosing that but publicly being expected to be a developer. Choose who to be and be who you choose.

About developers

If programmers are focused intently on a narrow and often technical problem, developers focus on much broader and often business-centric problems. The broader problem that developers are challenged with may need nothing to be programmed nor tested or designed. They care that the solution meets the need. They care that it is usable and valuable and they seek feedback to those ends.

There is always a big picture and developers make time and head space to understand it and be part of evolving and delivering it.
Developers seek feedback and are prepared to do whatever is needed to get to it. Developers seek collaboration with other developers because they realise it takes more than their specialisation to deliver a solution. This collaboration takes behaviors often missing in certain functions and developers seek to gain those behaviors so that they can collaborate better.

Critically developers recognise that the most functionally correct thing is not the same as the most effective solution. They know when enough is good enough.

In my line of work, I come across many functional specialists who complain they often do not have enough to do during an iteration. They often say this when there is an abundance of work to be done to deliver the solution. They argue that it is inefficient or ‘poor resource utilization’ for a programmer to test or get involved with elaborating requirements. A developer contributes in whatever way they can to develop the solution.

Re-defining the development Team

A development team contains developers. A cross functional development team contains developers who together are able to perform all the functions required to deliver the solution.

A developer is, almost always, also a functional specialist. That is they have the attitude and have deep skills in one or more functions.

A development team is fundamentally a learning vehicle. Its members recognise that in order for each person to consistently and effectively contribute to the solution that they must they learn from each other. They know that sometimes the nature of the work needs different measures of the functions and they adopt behaviors – like pairing – to create that learning towards helping each developer contribute as much as they can. So programmers learn to test and design and do configuration management – at least a little. Testers learn to code and design and manage configuration. At least enough to be useful.

Why I wrote this

I wrote this post because it I consider it to be cruel to expect people to be what they don’t want to be and worse still, to penalise them when they do not meet those expectations. This cruelty saddens me deeply.

I wrote this because I witness the violence that is done in the name of delivering software and I have unwittingly been part of that violence. From the sense of exclusion encouraged by functional silos to the treating of certain functions as second class citizens, peoples’ feelings are marginalised and their needs ignored.

I wrote this because I sincerely want organisations and specifically their management to understand the distinction between the attitude and the function. I want them to act more humanely when they hire and when they reward. I want them to explore more non-violent ways to design an environment that encourages developers AND functional excellence.

I wrote this because I want programmers to understand what is expected of a ‘developer’ and to make an informed decision whether they want that. I want them to make that choice without coercion.

If they choose to be a developer, they accept that they may be called upon to do things not in their expertise and they do so happily. I want them to fully realise that their choice means they are interested both in the joy of programming as well as the satisfaction of developing something that makes a difference.

Finally, I wrote this so that the word ‘programmer’ is no longer considered synonymous with ‘developer’. I believe that, by breaking this defacto equivalence, programmers will be happier people and simultaneously other functional specialists will feel equal and included partners in delivering a solution that meets a need.

What do you think?

If you are a developer, do you recognise that it is an attitude and not a function? If not, why not?
Do you disagree with the distinction between developer and programmer? I’d love to know why you think they are not different.
What are your experiences of one being confused with the other?

I’d love you to drop me a comment below or let’s chat it out on Twitter.