Collecting Accurate Software Development Process Data

Question - how do you improve a process?

Answer - collect data and analyze the collected data!

Unfortunately, the real answer is not as simple as above.

The real answer is - collect accurate data, rest is pretty easy to figure out!

In fact, the answer is far too complex than even the above, especially when it comes to software development processes.

Tooling and automation, artifical intelligence, machine learning, cognitive science, etc. can supposedly turn software development into a machine-driven process.

However, the current reality is that software developement remains a highly human-driven process.

For human-driven processes, availability of highly skilled and highly motivated people is a sine-qua-non.

And that makes collecting accurate software development process data and using it to improve software development processes extremely challenging.

It is useful to collect the following data in a software project to manage it effectively and to improve the processes employed.
  • Size - how big is the project? how much work needs to be done?
  • Effort - how many man-days are needed to develop the software?
  • Schedule - how much calendar time will it take to ship the software?
  • Cost - how many dollars will it cost to build the software?
  • Defect - what is quality level of the software?
The foresmost observation anyone with a keen eye will make - all the above depend on subjective judjment of the person performing the related activities.

The above statement is a stark reminder of the challenging fact that collecting software development process data is extremely difficult.

It violates the necesary conditions to get accurate data.

Condition 1 - Method and instrument to measure should be such that it can be benchmarked against a standard method and instrument. 
  • Temperature is measured in a consistent manner in terms of degrees centigrade using a thermometer.
  • Of course, need for calibration cannot be overstated in this context.
  • However, software process data like effort is measured in man-days which is very vague thing.
  • There is no standard benchmark for how many actual working hours constitute 1 man-day of effort.
Condition 2 - Entity measuring the selected parameter of a process should not be the one performing it
  • Entity for measuring can be the instrument or device used for measuring the selected parameter.
  • Temperature is measured using a thermometer. In an ideal scenario, the temperature gauge should operate without manual intervention.
  • However, software process data like effort for an activity is reported by the very person performing that activity.
  • The person performing the activity is also the entity measuring the selected parameter of the process.
  • This is quite strange and can never be expected to provide accurate data.
  • Why would a person not want to cautiously hide bad things and clamoursly highlight good things?
Despite the above challenges, there is a strong business imperative for measuring software development processes in a commecial context.

Software developement should not be seen as an engineering activity performed by the developer but as a business activity performed for the customer.

The above also implies that, software development processes need to viewed like any other business process.

So until ntil ways to address the above two conditions are not devised, collecting accurate software development process data will remain an elusive goal.