KEDE and the quality of code

Abstract

"Consider what effects, that might conceivably have practical bearings, we conceive the object of our conception to have. Then, our conception of these effects is the whole of our conception of the object." ~ Charles Peirce [1]

This quote emphasizes the importance of understanding and evaluating the usefulness or success of an idea or object. In the context of evaluating source code, Charles Peirce's pragmatic approach suggests that whether a piece of code is considered "smart" or "stupid" should be determined by its usefulness or effectiveness in achieving its intended purpose. This can be done by evaluating its performance, accuracy, integration, maintainability, scalability, readability, and test coverage.

To apply this criterion, you must consider the goals and requirements of the software or system that the code is a part of. Then, evaluate whether the code can effectively and efficiently achieve those goals and requirements. Effectiveness is measured by the outcome value produced. Efficiency is measured by the software development productivity, which is the ratio of the outcome value produced and the new knowledge discovered to produce that value.

The outcome value in the numerator can be revenue or profit, for example. The knowledge discovered in the denominator can be quantified using KEDE. Since KEDE is in the closed interval [0,100], the higher the KEDE, the higher the productivity assuming the outcome has not changed.

Productivity is high when less knowledge is needed to be discovered for the outcome value to be produced.

However, it's important to note that KEDE does not measure if a piece of code is smart or not. That's determined by the outcome value.

KEDE measures the difference between individual capability and work complexity.

Even if a developer has a high KEDE, but low outcome value, their productivity will still be low.

One may argue that this conclusion can be reached without involving KEDE, but they would be mistaken. KEDE provides the crucial insight into the difference between capability and work complexity, allowing for the calculation of productivity in software development. Without KEDE, there is no way to calculate productivity in software development.

Remember, more code doesn't mean high productivity. Valuable code produced faster does.

KEDE doesn't favor developers who write more code over those who write smart code.

Let's take a look at a numerical example in the next section.

Example calculation of software productivity

Let's take a look at some example code[2].

We'll call it "A", developed by a developer named "A". What can we say about the value of this code?

First, it has defects. For example, the function will return 10 full dots if the number (which is a float) is less than zero. Even if it didn't have defects, there are still some issues. Here are a few problems you might have with the example code:

• It doesn't look elegant
• There's a lot of redundancy, which can lead to bugs and typos
• It's hard to test. To understand what the function does, you'd need to check nine different inequalities for correctness and reason about ten conditionals and ten early returns.
• It's hard to maintain. For example, if you needed to change the color of the dot, or implement a trivial change request to output 9 dots instead of 10.
• The display logic is bundled in with the business logic.

A more iterative approach might be shorter, as shown below.

We'll refer to this code as "B," created by developer "B." What can we say about its value? It offers all the benefits that code A lacked.

Let's say code A provided $100 worth of value, and code B provided $400 worth of value. Roughly speaking, code A has 800 symbols, and code B has 200 symbols. Developer A had a KEDE of 50, which is the upper limit of human capability. So, developer A's productivity is the maximum possible if the outcome value stays the same. We'll use developer A's productivity as a benchmark. Let's see how changes in KEDE affect developer B's productivity. To do this, we'll keep the value and code size the same and vary only the development time needed to finish code B. The results are in the table below.

The first row shows the KEDE and productivity calculated values for developer A.

1. For KEDE=50 and a value of $100, productivity will be 100 $/bit.

The next three rows show what happens to developer B's productivity when the development time changes.

2. When Code B takes the same amount of development time as Code A, KEDE for B is four times lower than A, but B's productivity will be only 43% lower than A's productivity.
3. When Code B takes half the development time of Code A, KEDE for B is two times lower than A. However, B's productivity will be 33% higher than A's productivity.
4. When Code B takes a quarter of the development time of Code A, KEDE for B and A will be equal. But, B's productivity will be 400% higher than A's productivity.

Conclusion

We see that developer A produced four times more code than developer B, but due to its low value, productivity was low. Developer A had a KEDE of 50, which is the upper limit of human capability. This means that developer A's productivity is the highest possible when the outcome value stays the same.

One may think that this conclusion could be reached without involving KEDE, but they would be wrong. KEDE provided the crucial insight into the difference between capability and work complexity, which allowed for calculating productivity. Without KEDE, there is no way to measure productivity in software development.

More code doesn't mean high productivity. Producing valuable code faster is what matters.

KEDE doesn't favor developers who write more code instead of smart code.

Appendix

In order to calculate KEDE we use the following simplified formula:

Using KEDE, you can calculate the Knowledge Discovered and plug it into the denominator of the productivity formula:

Developer A's productivity:

Developer A contributed 800 symbols in 8 minutes. KEDE will be as follows:

With a KEDE value of 50, productivity will be as follows:

Developer B's productivity:

Development time of 8 minutes:

If developer B contributed 200 symbols in 8 minutes, KEDE will be as follows:

With a KEDE value of 12.5, productivity will be as follows:

Development time of 4 minutes

If developer B contributed 200 symbols in 4 minutes, KEDE will be as follows:

With a KEDE value of 25, productivity will be as follows:

Development time of 2 minutes

If developer B contributed 200 symbols in 2 minutes, KEDE will be as follows:

With a KEDE value of 50, productivity will be as follows: