Psychiatrists report play is important for keeping our minds and bodies healthy and happy. It has been uncovered that without at least some play, we mentally and physically deteriorate. Lack of play can lead to depression. Our brains are so hardwired in their need for playful activities that without such expressions we loose focus. Play enhances the creativity and imagination within us. Likewise, play has a proper role within our work. And not just for the psychological benefit to the individual, but for the overall health of the organization. For an IT development group, play is essential for finding better ways to approach problems. Within an IT context, play involves evaluating new ways to handle old problems. Prototyping, at times, constitutes play. Prototypes can be used for more than just the practicalities of the user interface; sometimes a prototype of specific functions is necessary for comparisons in order to judge how non-obvious techniques may perform. Such prototype endeavors can involve not only new algorithms, but potentially variant data structures. Ideally, such prototypes will improve team understanding of the data structures and offer insights into potential new and innovative approaches.
Thoughts can often act like a virus infecting our minds. If we think something is true, then we will act as if it is true. Pressure to deliver solutions quickly will always be knocking on our door. This pressure to deliver quickly may short-circuit our judgment; and rather than explore the array of possibilities that might address a problem, an easy answer will be employed which will likely produce results exactly like those used last time, or default to the seemingly "obvious" steps or options. People frequently become infected with limiting thoughts. Without the chance to try out varying approaches, developers will assume that any issue which they encountered once remains always true so that situations justifying a one-time "work around" become institutionalized in a zombie-like repetition, even long after circumstances and internal optimizations within the DBMS have changed. Back in the day, the first version of DB2 sorted things poorly. It was a long time before developers felt safe to place an ORDER BY clause in the SQL that executed within their processes.
Without play we only have a single answer. Without time for play we only have the time for doing things once so that for good or for bad they are done forever. Agile approaches try to incorporate the ability to play with new tactics under the guise of refactoring; but in practice, refactoring is meant to quickly address incremental improvement. Quickly always seems to be the requirement. Therefore, drastic changes in approach are less likely to emerge as an option, unless they are first played with and expanded, which will take some time and likely impact the "quickly" requirement.
While the globe is circled by many people every day, exploration is not a dead art. By playing with alternative approaches for the solutions we seek, we open the door to moving past our previous limitations. And while now and again we might simply reinforce pre-existing beliefs, without such testing of what we believe, we will be like the proverbial person who only has a hammer and subsequently treats every problem as if it were a nail. If we never look for other options, we shouldn't be surprised if we never find new options. Solution management needs to have the courage to commit to some level of playful exploration. Ultimately, the benefits will outweigh the costs. Breaking apart a problem into tiny pieces and then rebuilding those pieces in new configurations allows for innovation to appear, like the phoenix rising from the ashes.