pliantalliance.org

Pliant: Build Your Own Rules Of Thumb

About pliantalliance.org

Posted in Main by tbeck on December 28th, 2005

pli·ant /ˈplaɪənt/
adj.

  1. Easily bent or flexed; pliable.
  2. Easily altered or modified to fit conditions; adaptable.
  3. Yielding readily to influence or domination; compliant.
Related forms:

pli·an·cy, pli·ant·ness, noun
pli·ant·ly, adv.

Welcome to pliantalliance.org. This is the home of Pliant Software Development, a new way of thinking about developing software. PSD does not mandate any specific techniques, methodologies, processes or tools. Instead, PSD simply mandates that we think, evaluate and change what we are doing in order to get better at developing software. We believe that there are no definable, concrete steps for developing software successfully in all situations. This is because there are such a vast number of processes, techniques, ideas, idioms, tools, and methodologies in software development that it is impossible to evaluate and compare them with a sufficient project sample size.

We also believe that “success” can be defined in a myriad of ways by different people and organizations, so even if someone could compare all the techniques, they would then have to correlate those statistics with what people want to achieve from their software development effort. Moreover, no two software projects are exactly the same so we quickly come to the conclusion that defining a set of steps or techniques for successful software development in all situations is nearly impossible.

I’m reminded of my algorithm analysis professor in university. After every complexity calculation, when we had figured out that our algorithm was O(whatever), the prof would ask, “Can we do better?”. And then he would proceed to solve the problem with an algorithm that had complexity O(better than whatever). He would continue to ask, “Can we do better?” until we had mathematically proven that we couldn’t do better. It got so that the class would all say in chorus “Can we do better?” after every proof. The difference with software development is that we cannot mathematically prove that the way we are doing things is the best way. This isn’t a bubble sort. This is a really really tough problem. But, that shouldn’t stop us from asking, “Can we do better?” because the answer is likely to be, “Yes.”

If we can’t _know_ “the best way”, we obviously can’t _do_ “the best way”, so what do we do instead?

Again, there is no right answer. Therefore, there is no point in trying to find one. What we must do is strive to adapt our processes so that we get better at developing software. As the definition at the top of this page implies, in order to be pliant, we must bend or fold our current process to fit the situation we are facing. Since the situation is constantly changing, we have to be constantly changing our process.

We want to emphasize that we at pliantalliance.org have no answers for you. We also don’t believe that anyone else has answers for you, but there exists many suggestions and examples of success in other situations. These MAY work for you, but they may not. If they don’t, then stop doing what you are doing and try something else. If you always do what you’ve always done, you’ll always get what you’ve always got. We won’t reiterate the techniques and processes that more experienced and knowledgeable people have written and spoken about for years. There are clearly lots of things that have worked in some situations in the real world. If there wasn’t then the software development industry would be in deeper trouble then it currently finds itself. But, we believe that attaching yourself to one particular technique and going down with the ship is just foolhardy and a waste of time and money. No matter what guru came up with it, no matter how many people are practicing it, no matter how many projects have been “successful” because of it, no matter how many books and papers have been written about it, each of us is responsible for evaluating a process or technique before applying it to our project. More importantly, we are also each responsible for ceasing to use a technique if it doesn’t add value to our overall software development effort.

There are no guarantees. Every situation is different. There is no one process that will be invariably successful in all of your software development situations. Think, Evaluate, Change.

Comments are closed.