Exploratory Style of Software Development

 The exploratory program development style refers to an informal development style refers to an informal development style where the programmer makes use of his own intuition to develop a program rather than making use of the systematic body of knowledge categorized under the software discipline.  The exploratory development style gives complete freedom to the programmer to choose the activities using which to develop software. Though the exploratory style imposes no rules a typical development starts after an initial briefing from the customer. Based on this briefing, the development starts after an initial briefing from the customer. Based on this briefing, the developers start coding to develop a working program. The software is tested and the bugs found are fixed. This cycle of testing, and bug fixing continues till the software works satisfactorily for the customer. A schematic of this work sequence in a build and fix style has been shown graphically in Figure 1. Observe that coding starts after an initial customer briefing about what is required. After the program development is complete, a test and fix cycle continues till the programs becomes acceptable to the customer.

{tocify} $title= {Table of Contents}

An Exploratory development style can be successful when used for developing very small programs, and not for professional software. We had examined this issue with the help of the petty contractor analogy. Now let us this issue more carefully.

What is wrong with the exploratory style of software development?

Though the exploratory software development style is intuitively obvious, no software team can remain competitive if it uses this style of software development. Let us examine investigate the reasons behind this. In an exploratory development scenario, let us examine how do the effort and time required to develop a professional software increases with the increase in program size. Let us first consider that exploratory style is being used to develop professional software. The increase in development effort and time with problem size has been indicated in figure 2. Observe the thick line plot that represents the case in which the exploratory style is used to develop a program. It can be seen that as the program size increases, the required effort and time increases almost exponentially. For large problems, if would take too long and cost too much to be practically meaningful to develop the program using the exploratory style of development. The exploratory development approach is said to break down after the size of the program to de developed increases beyond certain value. For example, using the exploratory style, you may easily solve a problem that requires writing 1000 or 2000 lines of source code. But, if you are asked to solve a problem that would require writing one million lines of source code, you may never be able to complete it using the exploratory style; irrespective of the amount time or effort you might invest to solve it. Now observe the thin solid line plot in figure 2 which represents the case when development is carried out using software engineering principles. In this case, it becomes possible to solve a problem with effort and time that is almost linear in program size. On the other hand, if programs could be written automatically by machines, then the increase in effort and time with size would be even closer to a linear (dotted line plot) increase with size.

Now let us try to understand why does the effort required to develop a program grow exponentially with program size when the exploratory style is used and then this approach to develop a program completely breaks down when the program size become large? To get an insight into the answer to this question, we need to have some knowledge of human cognitive limitations. As we shall see, the perceived (or physiological) complexity of a problem is not related to the time or space complexity issue with which you are likely to be familiar with from a basic course on algorithms.

Even if the exploratory style causes the perceived difficulty of a problem to grow exponentially due to human cognitive limitations, how do the software engineering principles help to contain this exponential rise in principles help to contain this exponential rise in complexity with problem size and hold it down to almost a linear increase? We will discuss in later of this tutorial that software engineering principle help achieve this by profusely making use of abstraction and decomposition techniques to overcome the human cognitive limitations.

You may still wonder that software engineering principles are used, why does the curve not become completely linear. The answer is that it is very difficult to apply the curve not become completely linear? The answer is that it is very difficult to apply the decomposing and abstraction principles to completely overcome the problem complexity.

NOTE: The psychological or perceived complexity of a problem concerns the difficulty level experienced by a programmer while solving the problem using the exploratory development style.

Summary of the shortcomings of the exploratory style of software development:

We briefly summarise the important shortcomings of using the exploratory development style to develop to professional software:

•          The foremost difficulty is the exponential growth of development time and effort with problem size and large-sized software becomes almost impossible using this style of development.
•          The exploratory style usually results in unmaintainable code. The reason for this is that any code developed without proper design without proper design would result in highly unstructured and poor quality code.
•          It becomes very difficult to use the exploratory style in a team development environment. In the exploratory style, the development work is undertaken without any proper design and documentation. Therefore it becomes very difficult to meaningfully partition the work among a set of developers who can work concurrently. On the other hand, team development is indispensable for developing modern software- most software mandate huge development efforts, necessitating team effort for developing these. Besides poor quality code, lack of proper documentation makes any later maintenance of the code very difficult.