Buddha’s third noble truth states that ‘The cessation of suffering is attainable’. This expresses the idea that suffering can be ended by achieving dispassion, the unmaking of sensual craving and conceptual attachment. The result is a state of Nirvana, which can translate to freedom from all worries, troubles, complexes, fabrications and ideas. Sounds great, huh. I don’t know about you but I’m ready for Nirvana right now.
The phrase ‘fabrications and ideas’ is interesting to me here. My first inclination was that this meant ‘design is bad’ as one should let go of having any idea of the future. Upon further examination, my opinion is that this is not necessarily translating into ‘design is bad’ but is more in line with the second noble truth in that the future is constantly changing. One can only truly design for today. Design is ‘good’ if it is simply a construct of how the product should evolve from a technical perspective but allow for a shifting future. This is one of the things I like about SOLID architecture principles in that my opinion is that it allows for this easily changing components. So now you have a ‘basic’ design in place using architectural principles such as SOLID to allow for shifting futures, how do you manage the day to day development team with the thought that cessation of suffering is attainable?
The beauty of Kanban is that by limiting throughput of feature requests or change in general, you limit the wandering of the mind into things of tomorrow that may never come to be. Suffering from a developers viewpoint occurs when time is wasted on events (or designs) that never come to fruition. The ‘worries’ of tomorrow can be shielded from developers by limiting the throughout of the backlog. The team only looks at what is truly prioritized for the immediate cycle. This acknowledges that the future is constantly shifting so why plan on things that you may never do. The product owner simply moves the next important requirement at the time into the backlog when one is needed for replacement. Only plan for what can be managed in the short-term of a release duration.
Developers pull an item from the backlog into the ‘in-progress’ bucket when they are ready for work. The in-progress bucket is also limited in throughout so that it reduces distractions as of the result of working on too many tasks at one time. The length of time for task completion can also be reduced by allowing for this mindful focus. Developers get the satisfaction of getting more frequent visualization of completed tasks and spend less time in wasteful futures planning.
So can Nirvana be achieved in software development? I like to think so and believe Kanban is the noble path to achieve this which leads us to the fourth noble truth which talks about the path. We will get into that discussion next.
The phrase ‘fabrications and ideas’ is interesting to me here. My first inclination was that this meant ‘design is bad’ as one should let go of having any idea of the future. Upon further examination, my opinion is that this is not necessarily translating into ‘design is bad’ but is more in line with the second noble truth in that the future is constantly changing. One can only truly design for today. Design is ‘good’ if it is simply a construct of how the product should evolve from a technical perspective but allow for a shifting future. This is one of the things I like about SOLID architecture principles in that my opinion is that it allows for this easily changing components. So now you have a ‘basic’ design in place using architectural principles such as SOLID to allow for shifting futures, how do you manage the day to day development team with the thought that cessation of suffering is attainable?
The beauty of Kanban is that by limiting throughput of feature requests or change in general, you limit the wandering of the mind into things of tomorrow that may never come to be. Suffering from a developers viewpoint occurs when time is wasted on events (or designs) that never come to fruition. The ‘worries’ of tomorrow can be shielded from developers by limiting the throughout of the backlog. The team only looks at what is truly prioritized for the immediate cycle. This acknowledges that the future is constantly shifting so why plan on things that you may never do. The product owner simply moves the next important requirement at the time into the backlog when one is needed for replacement. Only plan for what can be managed in the short-term of a release duration.
Developers pull an item from the backlog into the ‘in-progress’ bucket when they are ready for work. The in-progress bucket is also limited in throughout so that it reduces distractions as of the result of working on too many tasks at one time. The length of time for task completion can also be reduced by allowing for this mindful focus. Developers get the satisfaction of getting more frequent visualization of completed tasks and spend less time in wasteful futures planning.
So can Nirvana be achieved in software development? I like to think so and believe Kanban is the noble path to achieve this which leads us to the fourth noble truth which talks about the path. We will get into that discussion next.
No comments:
Post a Comment