There's a significant difference of attitudes towards specifications that I see in developer colleagues close to me. Groups with attitudes seems to be equally strong in numbers, so this is not isolated behaviour of one individual.
The first group seems to take specifications as something given from the outside. They seem to believe in this other person thinking through the things that need to be implemented, and take their own sense of responsibility only within the context of that spec. While testing and noticing that what was implemented just makes little sense, these people easily revert to defensive. They say that not being able to do things related to the purpose of the feature is a matter of opinion and that they cannot work on the fixes before someone specifies the wanted behaviours. Occasionally, they also get very strong voices in discussion of what is a bug vs. change, being right about the idea that most bugs would be things that they never considered in scope they accepted and thus changes. Getting hung up on the definition of defect vs. change does not help, it all is just work that may need get done and fighting over definitions is time away from implementing the necessary changes.
The second group seems to treat specifications given to them as useful fiction that starts conversations. These developers seem to be at ease with discussions that result in dropping features out of scope, finding the core of what needs to be done and implementing that first. They have no problems in making suggestions: it could be like this or like this, here are the pros and cons I see of these solutions. And their approach often seems to end up with a different solution than they suggested, building on the compromises and deeper understanding of what is being built.
Talking to people I place in the first group reveals a great deal of discomfort on how I would like to define the role of a developer in relation to their definitions. While I feel I thrive with the idea of making decisions of how things end up being (until changed as we learn), these people seem to be drawn way out of their comfort zones in making a decision and thinking through the consequences.
It seems I will end up having an equal amount of both in my teams, and I'm thinking about how to make the first group willing and able to join the ranks of the latter group. People in the first group are really dependent on someone testing a great deal for them, someone specifying for them whereas the latter group is more independent and self-contained. It has a direct impact on portions of other specialists we need to add to the teams. Both of these go with "developer" title but have significantly different results how ready things end up being after them.
Pairing people up is one approach, but it seems not to be enough. The rejection of responsibility towards specifying behaviours and externalising that seems to come from an early lesson learned, that seems very hard to unlearn.
I'm curious as to if people have found ways of growing themselves out of patterns like this, and what would be the key realisation for the change to happen. Some suggest that old dogs don't learn new tricks and we might just have to compensate for lack of tricks in one with another person in the team that will do the tricks missing from the palette.
I wonder when we will learn to build teams of growing individuals instead of thinking of filling role positions. Given a chance of choosing who to work with, I always take people from the second group. But I wonder if I would then be missing out on something with lack of this diversity.
The first group seems to take specifications as something given from the outside. They seem to believe in this other person thinking through the things that need to be implemented, and take their own sense of responsibility only within the context of that spec. While testing and noticing that what was implemented just makes little sense, these people easily revert to defensive. They say that not being able to do things related to the purpose of the feature is a matter of opinion and that they cannot work on the fixes before someone specifies the wanted behaviours. Occasionally, they also get very strong voices in discussion of what is a bug vs. change, being right about the idea that most bugs would be things that they never considered in scope they accepted and thus changes. Getting hung up on the definition of defect vs. change does not help, it all is just work that may need get done and fighting over definitions is time away from implementing the necessary changes.
The second group seems to treat specifications given to them as useful fiction that starts conversations. These developers seem to be at ease with discussions that result in dropping features out of scope, finding the core of what needs to be done and implementing that first. They have no problems in making suggestions: it could be like this or like this, here are the pros and cons I see of these solutions. And their approach often seems to end up with a different solution than they suggested, building on the compromises and deeper understanding of what is being built.
Talking to people I place in the first group reveals a great deal of discomfort on how I would like to define the role of a developer in relation to their definitions. While I feel I thrive with the idea of making decisions of how things end up being (until changed as we learn), these people seem to be drawn way out of their comfort zones in making a decision and thinking through the consequences.
It seems I will end up having an equal amount of both in my teams, and I'm thinking about how to make the first group willing and able to join the ranks of the latter group. People in the first group are really dependent on someone testing a great deal for them, someone specifying for them whereas the latter group is more independent and self-contained. It has a direct impact on portions of other specialists we need to add to the teams. Both of these go with "developer" title but have significantly different results how ready things end up being after them.
Pairing people up is one approach, but it seems not to be enough. The rejection of responsibility towards specifying behaviours and externalising that seems to come from an early lesson learned, that seems very hard to unlearn.
I'm curious as to if people have found ways of growing themselves out of patterns like this, and what would be the key realisation for the change to happen. Some suggest that old dogs don't learn new tricks and we might just have to compensate for lack of tricks in one with another person in the team that will do the tricks missing from the palette.
I wonder when we will learn to build teams of growing individuals instead of thinking of filling role positions. Given a chance of choosing who to work with, I always take people from the second group. But I wonder if I would then be missing out on something with lack of this diversity.
