When are grains of sand a pile?
Sorites Paradox was written in fourth century BCE, and today is very applicable to software development.
The paradox can be visualised by thinking of a collection of individual grains of sand. If you have 5 grains of sand you would probably agree that isn’t a pile of sand. Now add a grain of sand to those 5. Is it now a pile? Add another, now a pile? When different size collections (I’m trying not to use the word pile) of sand are put in front of you, it’s very easy to say this is a ‘pile’ and this one is not. But for any of those ‘piles’ of sand, when you start taking individual grains away it is impossible to define which grain of sand marks the transition between pile and not pile.
This paradox extrapolates when you want to talk about a range of sizes. Now we’re not just talking not pile/pile but a range of sizes… not pile, small pile, medium pile, large pile. In software we might easily bin such ranges into groups, but those groups are arbitrary on the point of transition, rather than defining the exact point the transition from that one state to another.
There is a variation of the paradox, with regard to colour and identifying if a set of coloured chips are the same colour or different.
https://en.wikipedia.org/wiki/Sorites_paradox
Those that are close together in colour are very difficult to determine if they are the same or not while those further apart on the colour scale can clearly be seen as different.
The tension between small changes and big consequences gives rise to the sorites paradox.
This has clear parallels with software development. When a team are planning (all with their different views of each other, themselves and the items of work being discussed) and it’s point poker or some other sizing estimation, the Fibonacci or power sequences may be used to try and give separation between the work items (piles) as the sequence gaps get larger as the size increases, but really it’s just trying to push against the fact it’s very difficult to see the difference in size and these discussions can end up taking up time that could be spent on development.
This is where Sorities paradox is impacting. Unless the piece of work is small, just a collection of grains that no one would argue is a pile (and even then these, ’not a pile’ items, can contain something that does then require significant time to implement, but, that’s development and on average they are normally short tasks), then trying to agree on what size the piece of work is will be very difficult, as no one can put their finger on the transition between sizes and significant time can be spent trying to size work.
All we can be sure about is the very small pieces of work, as everyone will look at those and agree it is a small piece of work. There maybe some ‘smaller’ jobs that are getting close to that point where many grains of sand have been added and now discussion are being had over the size of that piece of work - is it small or not. When the grains of sand add further, now everyone is trying to pick between multiple transition states, and the more options there are the more difficult it becomes to agree on where each item of work should sit and the paradox tells us it is impossible to identify. All of this is happening while team members potentially have differing mental model of what the feature is and what level of zoom they are viewing the feature.
So Sorites Paradox highlights the problem we have, how does it help in planning.
Level of zoom/mapping, that’s the next area to consider…