Empirical Software Engineering............... Is the cake here?

Are programmers artists or scientists? Do they craft monolithic structures based upon the will of their hands sculpting the world around them or perhaps delicately placing tiny organisms of Lego in specifically designed pockets point by point. Maybe the differentiation of these individuals spiral even further downward, the way code is written, a self proposed style possibly a kind of virtual fingerprint left behind in every program in every electronic device worldwide. Languages, generalised styles and taught practices may have their own guidelines for conformity but at the end of the day there will always be visionaries who will break rules doing things differently, advancing, perhaps with the normal distribution of the world following suit.

By empirically capturing habits and styles of  effective programmers a hypothesis can be designed, developed and tested to find optimum rates of productivity, efficiency and quality for a given project. The goal of this being to reduce all costs that could effect businesses in both the public and private sectors.

Tests and experiments that reduce the cost of a programmers time could be a programmatic level, cyclomatic complexity, or at a functional/practical level such as programmers working in pairs on the same screen of code tend to reduce the time and increase the quality. These latter tests are not without faults as there could be an array of extraneous variables that may bias the results in a particular fashion.

Reducing cost at a programmatic level is easier to control as a lower cyclomatic complexity can potentially reduce the amount of time for code maintenance. Here is a quick and simple example of how recursion can reduce the amount of complexity in finding a particular number in a range but may add to processing overhead.

int findMe = 5;
int finder = 1;
int maxRange = 10;

function findTheInt() {
    while(finder<maxRange) {
         if(finder==findMe) {
                     print("found number");
                     break;
         } else {
                     finder++;
    }
}
}

// By implementing a recursive function the while loop is taken out therefore reducing the potential maintenance cost.


function findTheIntRecursive() {
         if(finder==findMe) {
                     print("found number");
         } else {
                     finder++;
                     findTheIntRecursive();
    }
}


The next question which tends to be asked is, "Why is this testing necessary aren't effective programmers discovered based upon experience gained in the industry as well as professional accreditation?". This is a true statement but with an empirical system of analysis standards that are the backbone of professional accreditation can be unfolded and tested to be proven to work or even gradually evolve.

Developing an early prototypical model of effective evaluated approaches to reduce all costs sounds like a great idea. In order to gain public appeal practical measures will have to be implemented that would aid understandability and convenience for everyone in the target audience. This would include managers, programmers, directors and clients all of which would require different targeted advantages that would be offered as well as a communication plan that specifically tailor made for each type of individual in the target market. To paraphrase even though the approaches would result in the same outcome they need to be marketed towards the range of the target audience in different ways.

Here are some examples that would be targeted to specific groups...

- Programmers are the technical staff a tool/technique may help there work easier. This could be communicated at a very low level that would satisfy their need to understand at a bottom up level.

- Managers understand the low level advantages but are torn between their team versus management deadlines. The main advantage targeted here as that the reduction of cost in training, design and implementation.

- Directors/Management are interested in the bottom line, the profit margin. If an approach toward manufacturing/development doesn't deliver then it maybe cut from the budget entirely.

UML is an example of an empirical style of using the best elements for software design. It was implemented in the early 1990s, to combine and filter all the best methods of software design documents. Programmers are taught UML but it is rarely used in the industry, why is this? It has been proven that diagrams used in the design of software life cycle are used to communicate an idea to peers rather as formal documentation. Will empirical software engineering be the UML of the next decade only time will tell...

References
http://www.jameslewiscoleman.info/jlc_stuff/project_research/On%20the%20application%20of%20measurement%20theory%20in%20software%20engineering.pdf

http://www.americanscientist.org/issues/pub/empirical-software-engineering

http://alarcos.esi.uclm.es/doc/MetoTecInfInf/Articulos/tichy-hintsreview-ese-2000.pdf