Buddha and Popper: The Processless Process
Buddhism teaches the doctrine of non-attachment, in which practitioners are encouraged to avoid grasping at and attaching to physical and mental objects. Actually, there is no distinction between physical and mental objects, but that is an entirely different discussion.
Popper's philosophy of science teaches the doctrine of expressing a hypothesis as a falsifiable statement, in which practitioners are encouraged to attempt to falsify the hypothesis through experimentation.
Good science benefits from non-attachment. This is because the job of the scientist is to seek knowledge through falsification-minded experimentation, not to seek external validation for their ideas through verification-minded experimentation. Science puts an idea through a rigorous battery of tests, and if the hypothesis is not rejected by the tests, then there is a chance that the hypothesis might be valid.
This is an inversion of the way that most people think, and it might even go directly against human nature. Some research shows that we might develop strong attachment to things that we own, including ideas once we "take ownership" of them. You can read about some of this research in popular social science books like "Predictably Irrational."
When we cling to our ideas, our ideology becomes rigid, we slip into the verification mindset, and the result is bad science. It is easy to concoct data and results that validate a given hypothesis; particularly with the help of many common and egregious abuses of statistics. In the most extreme case, emotion and political agenda drive the verification mindset, as is often the case in the current global warming debate.
The same spirit is also beneficial in business. A lot of people get fixed on a particular method of operation (processes, practices, and so forth.) Agile software development processes seem to bring about an especially heated debate among self-proclaimed adherents of waterfall, agile, anti-agile, lean, and "who needs process." In the agile world, there has been a recent boom in popularity of so-called lean processes. Lean is cool in so far as it relates to what I am talking about here; non-attachment to a specific process, and a constant focus on discovering and eliminating inferiority (waste) in your current process.
Henry Ford wrote two of my favorite books about business. What struck me above anything else is his attitude to constantly question what Ford was doing, what others were doing, and to constantly look for a better way to do things. This attitude resulted in one of the most innovative and successful enterprises in history. In one story from the books, Ford recounts how they invented a new process for producing plate glass. They had to do it without any experts in glass manufacturing in order to get the proper level of non-attachment required to innovate. They also created the assembly line in order to avoid waste in moving materials and unfinished product around during the process of manufacturing. The purchased companies and assets required to produce the raw materials they needed. They refined the process of extracting those materials and transporting them to their manufacturing plants so that they could have a steady supply of materials arriving on demand. They avoided interruptions in supply or unacceptable volatility and magnitude of price that they might otherwise experience from dependencies on external suppliers.
I talk more about Ford in this related post where I also highlight what happens when you just poach and apply ideas without getting to the spirit that underlies the ideas and applying your own critical thinking.
There is a good article by James Share discussing "the death of agile" and his experience rescuing projects that claim to be using scrum but have failed to adopt quality technical practices. This is a very important point. If you are doing something poorly, and you attempt to fix the situation by poaching and applying ideas without understanding them, you may not even be addressing the issue at all, and you might end up performing just as poorly. You have to start by observing what you are doing and the results you are achieving as objectively as possible or order to see what you are doing poorly. Then you have a chance at addressing the problems and improving performance.
This can be very difficult in light of the "don't know what you don't know" problem. Until you reach a certain level of competence, you are incapable of seeing what you do not know, and as a result, are also incapable of seeing what others know, so you are unable to see what you or your organization is doing poorly and devise valid strategies to increase performance. Unfortunately "years of experience" is not a proxy for competence. I have seen large numbers of experienced people in a variety of businesses who "don't know what they don't know."
Even more unfortunate is the fact that track record alone is also not a valid proxy for competence. I have also seen large numbers of people who appear to have a good track record, who then go on to show their true level of competence in a spectacular blow up; demonstrating that their track record had been driven predominantly by chance conditions or the work of others.
I like XP, agile, and lean. I have learned evolutionary bottom-up design, TDD, refactoring, pairing, user scenarios, user stories, product development, and project tracking. I try to have an insight into how things are going at all levels of business and technical granularity in order to decrease the risk of wasting effort on the wrong problems or the wrong solutions. I don't do iterations or high ceremony planning and estimating. I don't really do estimating at all. I just try to keep my stories all around the same size. Sometimes they are a little bigger and I just leave them that way - it averages out. You have to get good at breaking big problems down into smaller abstractions in order to work this way. This is not going to work for you if you are not consistently breaking down problems into small enough chunks. You also need to be accustomed to consistent delivery. Sometimes people need the discipline of iterations to break the cycle of procrastination before the iteration-less pull-through model starts to make any sense.
I think a good goal is to release the right solution to the right problem, consistently, from head, without the need for more than a few rollbacks per year due to top priority bugs. Experiment with your approach, measure, and see how you can make progress on this objective.
Reader Comments (1)
Excellent Popper reference, I don't encounter too many people these days that appreciate his contributions and essays on verisimilitude and falsifiable science.