Back in the days when agile was new to me, a lot of teams played all sorts of games to learn about the dynamics relevant to software development. Some of the best training courses included a simulation of some sort - maybe they still do.
I played the Marshmallow Challenge with Antti Kirjavainen at Tampere Goes Agile, and thinking of it, I realize it has been a long time since I've been playing any of these agile games.
One game that I remember particularly fondly is the Bottleneck game. I'm thinking of that game today, as I'm thinking about bottlenecks and people's attitudes.
A lot of times talking with programmers, I sense an idea of self-worth in writing code. It's true, there isn't a program we can run (and test) if there isn't the act of writing the code. However, looking at professional programmers in action by sitting next to them, you see that clearly it's not all about writing the code.
In fact, writing the code is hardly the bottleneck. Thinking smart to be able to write the right code is. And for a non-programming programmer like me, thinking together, in right kind of batches, tends to be the contribution I seek to improve.
Without writing the code, the thinking isn't complete. It's still a theory. The trust we experience in testing the system is in the part of the thinking that ended up in the code.
I also find it absolutely fascinating to look at programmers thinking about a line of code together. Having that chance (by inviting myself into that chance) I've learned that for each line we write, we have a lot of options. I remember looking at one of those cases unfold in particular, in a mob format.
We were replacing a component with another. We were not particularly good at talking in intent, all we knew is we need to take out calls to one component and replace then with calls to another. And very early on, someone suggests a way to do a thing. Someone else suggests another option. And another. And very soon there's suggestion of something none would have suggested without hearing the other suggestions. And that feeds into yet another suggestion.
While a lot of times we would go about doing all, we did not because we did not actually propose those as ways of doing. We listed them as possible ways of doing it. From doing the one selected, we still built more on top of the experience.
In a period of just a few minutes so many things happened. And all these things were about thinking, and bringing in various perspectives and experiences into that thinking. It made me realize that each line of code can have a lot of options on what it includes. From a perspective of a tester, those options have implications. Being a non-programming programmer further away from code, I would not see or understand those implications quite the same way.
The amount of tradeoffs in selections in building software is fascinating. The idea of getting it to work is so different from getting it to work just right for all the criteria we can be thinking of: the rightness for this particular technology, the rightness for future maintenance and extendability, the rightness for performance and security considerations.
So all of this leads me to think about the problems I'm experiencing in (some) developer thinking. The problems of "just tell me the requirements", "just specify what it needs to do". The problems of not volunteering to finish the details when the big lines have already been implemented. The problems of not caring about side effects when there's at least some way it already works. The problems of not considering future self and others in maintaining the code. The unwillingness to cross necessary technological borders and rather waiting for someone else to do their bit and solving problems in the interface together, real time. The inability to spend time on testing with an open mind to learn about things that didn't quite work as intended, that we did not even know to expect.
A lot of times the other thinkers, like product owners and testers are around to compensate for the programmer interests. But I still appreciate the programmers who can do all of these types of things the most.
And I find that they usually don't exist, except momentarily. And in programmer groups when they are in their best behavior.
I played the Marshmallow Challenge with Antti Kirjavainen at Tampere Goes Agile, and thinking of it, I realize it has been a long time since I've been playing any of these agile games.
One game that I remember particularly fondly is the Bottleneck game. I'm thinking of that game today, as I'm thinking about bottlenecks and people's attitudes.
A lot of times talking with programmers, I sense an idea of self-worth in writing code. It's true, there isn't a program we can run (and test) if there isn't the act of writing the code. However, looking at professional programmers in action by sitting next to them, you see that clearly it's not all about writing the code.
In fact, writing the code is hardly the bottleneck. Thinking smart to be able to write the right code is. And for a non-programming programmer like me, thinking together, in right kind of batches, tends to be the contribution I seek to improve.
Without writing the code, the thinking isn't complete. It's still a theory. The trust we experience in testing the system is in the part of the thinking that ended up in the code.
I also find it absolutely fascinating to look at programmers thinking about a line of code together. Having that chance (by inviting myself into that chance) I've learned that for each line we write, we have a lot of options. I remember looking at one of those cases unfold in particular, in a mob format.
We were replacing a component with another. We were not particularly good at talking in intent, all we knew is we need to take out calls to one component and replace then with calls to another. And very early on, someone suggests a way to do a thing. Someone else suggests another option. And another. And very soon there's suggestion of something none would have suggested without hearing the other suggestions. And that feeds into yet another suggestion.
While a lot of times we would go about doing all, we did not because we did not actually propose those as ways of doing. We listed them as possible ways of doing it. From doing the one selected, we still built more on top of the experience.
In a period of just a few minutes so many things happened. And all these things were about thinking, and bringing in various perspectives and experiences into that thinking. It made me realize that each line of code can have a lot of options on what it includes. From a perspective of a tester, those options have implications. Being a non-programming programmer further away from code, I would not see or understand those implications quite the same way.
The amount of tradeoffs in selections in building software is fascinating. The idea of getting it to work is so different from getting it to work just right for all the criteria we can be thinking of: the rightness for this particular technology, the rightness for future maintenance and extendability, the rightness for performance and security considerations.
So all of this leads me to think about the problems I'm experiencing in (some) developer thinking. The problems of "just tell me the requirements", "just specify what it needs to do". The problems of not volunteering to finish the details when the big lines have already been implemented. The problems of not caring about side effects when there's at least some way it already works. The problems of not considering future self and others in maintaining the code. The unwillingness to cross necessary technological borders and rather waiting for someone else to do their bit and solving problems in the interface together, real time. The inability to spend time on testing with an open mind to learn about things that didn't quite work as intended, that we did not even know to expect.
A lot of times the other thinkers, like product owners and testers are around to compensate for the programmer interests. But I still appreciate the programmers who can do all of these types of things the most.
And I find that they usually don't exist, except momentarily. And in programmer groups when they are in their best behavior.
