Thursday, 11 September 2014

First of all a very warm welcome on my blog on the ways to develop software products based on nondeterministic methods!
In order to define what nondeterministic method means let's have a look at what is a deterministic process.
Imagine you're working in a factory which produces bikes. The production line comprises of  several steps in which bike parts (frame, wheels, saddle etc.) are added to make a final product. There    is a strict order that must be followed while producing a bike. For example you get first a frame and then you add a front wheel to it and then you add a hand break and so forth. There is an assigned value (for the sake of argument let's call it delivery time) to each step which says how much time it takes to finalise the step. As a result it takes sum of all delivery times to produce one bike. Planning is easy. If you produce 200 bikes per day then once you get an order for 1000 bikes you can easily calculate that it will take you 5 consecutive days to fulfil the order. That's an ideal deterministic system.
The situation gets less easy when with every order there are some details which vary like a sticker, a colour or shape of a saddle. Such variability spoils the system of production because every time you get an order you need to adapt the production process and can't simply follow the same steps. Additionally there are some other factors which you have to add to the planning equation like workers mood, probability of machine getting broken down or changing specs from your customers.
Of course such a system can still be managed by deterministic means just if you replace fixed values with average or median. Sounds good, doesn't it? But the predictability within such a system diminishes as a function of variance leaving you with a vague message to your customer like for example that the ordered items might be delivered anytime between 5 to 15 months. Arguably no one is going to fancy such news. And that's not the end of misery yet. Next to the quantitative differences (embraced by statistics) between the latter and former system there is a great chance of introduction of a qualitative change. Why is that? In the course of product creation you will make some decisions about how to deal with new requirements. Those decisions may have impact on further steps only once or twice - with an immediate result being completely different then a long term one. As a result you may face a significant flaw of your past decision later on in the process and your initial plan gets torn apart completely.
Well if above sounds familiar you face a complex system which can't be properly managed in a deterministic manner.

I believe that software production in most cases resembles complex system and therefore one should seek help in nondeterministic management methods then those which suit perfectly to deterministic environment.

There will be a lot on results and my experiences with agile software development in this blog. However, I will use agile only as an example of dealing with nondeterminism along with other topics (which will almost never collide with what agile says).

Enjoy!!