Software development methodology is an industry in and of itself. The processes are prescribed as cure-all tonics for success and with each new wave of methodology we get a new wave of startup founders describing themselves as often by their methodology as they do their products.
What disturbs me about this phenomenon is how little one methodology appears to learn from another. Each wave of methodology is less like an evolutionary step and more like a revolution of processes. This makes me trust even less in the prescribed process because it has the smell of alchemy rather than science.
A particular process, we are told, is the key to success. The texts describing the process rarely get deep into the thought, experimentation and reasoning behind the creation of the process except insomuch as they need to in order to convince you it’s correct. Advocates of a particular development methodology tend to have terse canned answers for why any part of the process is warranted. They have subscribed themselves to the process, not to the problem or the critical thinking that went into creating it.
The only timeless piece of advice we seem to have is “The Mythical Man-Month.” While nobody can tell me what solutions are prescribed (not many are), everyone knows the key piece of insight the book presents: You can’t throw bodies at a problem. The purpose of “The Mythical Man-Month” was not to prescribe a process for developing or manufacturing it was to break a common and pervasive misconception that you can get to market faster by adding human beings to a task. It presented its argument so well and so scientifically that its learnings are now taken for granted which is the greatest compliment we have in the world of technology.
I’d like to break another common and pervasive misconception, that subscription to a process can build great products.
We are in the most rapidly changing field the world has ever seen. The development, distribution and consumption of our products have changed dramatically in nearly as fast a cycle as the microprocessor. By the time a process can be described succinctly and put into text it is almost surely out of date.
Every process begins with a problem. Understanding the problem is more important than solving it. You gain a deep understanding of the problem through critical thinking. A process begins to develop to solve the problem. Your results when implementing the process will have a lot do with the culture you inject them into. Taking the process a startup might use and implementing it across a larger organization will not only encounter a lot of resistance but the participants will have different motivations and share a very different culture among the organization.
And there’s the rub. The problems change and require new critical thinking and organizations are different enough that process is not portable, so where is the value in describing or subscribing to a process?
We should be doing what “The Mythical Man-Month” did over 30 years ago. Describe the problem and present your critique. The thinking will have the life span of the problem. If you get lucky you might critique something as timeless as “adding humans” but most likely you’re going after something as timely as “how do we maintain momentum across a distributed team” or “how do we iterate on a product in faster and faster cycles” and your thinking about the problem is more portable than your solution.
A product is your solution to a problem. How is it that across such a diverse range of problems we see the same products over and over again? It’s because nobody is examining the problems critically, we’re all just layering the same set of processes and a few features (social, gamification) on to every problem.
More important than process is culture. If you build a culture that values critical thinking over process you’ll end up with better and more existing products. If you subscribe to a methodology your products will be the same shade of vanilla as your contemporaries.