Frequently Asked Questions

About KEDE and KEDEHub.

What is KEDE?

KEDE is an acronym for KnowledgE Discovery Efficiency. It is pronounced [ke.de].

KEDE is a ratio between the knowledge discovered and the maximum knowledge that could be discovered for a time period.

Where H is the amount of missing information as per the relationship of Shannon:

Below is an animated example of calculating KEDE when we search for a gold coin hidden in 1 of 64 boxes.

In all six cases the required knowledge is 6 bits. That means, we need tp ask six binary questions on average to find the gold coin. You can see that the knowledge to be discovered depends on the prior knowledge. KEDE reflects the knowledge discovered i.e. the difference between required knowledge and prior knowledge.

KEDE reflects the capability of knowledge workers to efficiently discover and apply knowledge.

Prior knowledge is the easiest and the fastest to discover - it is in the human head, one just applies it. In other words, when prior knowledge is applied then there is the most efficient knowledge discovery. Conversely, when a lot of knowledge is missing then the knowledge discovery is less efficient. The more prior knowledge was applied i.e. the less knowledge was missing the more efficient a Knowledge Discovery Process is.

The math definition of KEDE is available here.


What is the maximum KEDE value?

The math underlying KEDE dictates that the minimum KEDE value is 0 and the maximum value is 100.

    KEDE has the following properties:
  • Minimum value of 0 and maximum value of 100.
  • KEDE approaches 0 when the missing information is infinite. That is the case of humans creating new knowledge. Examples are intellectuals such as Albert Einstein and startups developing new technologies such as Paypal.
  • KEDE approaches 100 when the missing information is zero. That is the case of an omniscient being...like God!
  • KEDE will be higher if you don't spend time discovering new knowledge, but just applying existing knowledge.
  • KEDE is anchored to the natural constraint of maximum possible typing speed and thus supports comparisons across contexts, programming languages and applications.

We would expect KEDE of 20 for an expert full-time software developer, who mostly applies existing knowledge, but also creates new knowledge when needed.


How is KEDE calculated?

In order to calculate KEDE for software developers we use the below theorem:

Where:

  • S is the number of added symbols in a day;
  • h is the number of working hours in a day;
  • CPH is the maximum number of characters that could be contributed per hour;
  • H is the amount of missing information as per the relationship of Shannon:

The proof of the theorem is available here.

Using the above theorem KEDE values are calculated with the formula:

Where:

  • S is the number of added symbols in a day;
  • h is the number of working hours in a day;
  • CPH is the maximum number of characters that could be contributed per hour;
  • l are the hours wasted on non-productive activities;
  • W stands for the waste probability.

The above formula means that individual KEDE is:

  1. Inversely proportional to the difference between the level of knowledge the individual has and the level of knowledge required to do a job;
  2. Inversely proportional to the amount of waste the individual removes while doing the job;
  3. Inversely proportional to the amount of time wasted on non-productive activities;


KEDE is measuring how fast people type! How could that be trusted?

Short Answer: KnowledgE Discovery Efficiency (KEDE) can be measured using symbols contributed as proved by this math theorem.

Long Answer: There is no way to get inside a human's head and count the questions asked while discovering knowledge. The process of discovering knowledge is a black box. We pragmatically adopt the positivist credo that science should be based on observable facts, and decide to infer the number of questions asked solely from the observable quantities we can measure. In reality the only thing we can measure is the tangible output. Hence we have to use the number of symbols of source code created to infer the number of questions asked.

Below is a short video that demonstrates how by counting the symbols of source code created we can estimate the number of questions asked.

An analogy:

Joe is a novice driver, who has just received his driving licence. Joe has a total of 20 hours experience driving a car. Next to him is Don, who had received his driving licence 25 years ago. It is not clear how many hours Don spent driving a car, but it is in the thousands. Let's imagine Joe and Don take part in a car race. The race track features short straights that climb sharply uphill for a short time, then suddenly drop downhill and very fast left and right turns. In short - it is a challenging track. Drivers need to make only one lap - from Start to Finish. They are given the same car model to drive on the same racetrack - hence, they are on an equal footing. We are watching the race, but we are not aware which is Joe's car and which is Don's car. It is like a black box to us. Our goal is to tell which car is Joe's and which car is Don's. How can we tell? Well, if the track is the same and the cars are the same, then the best driver will finish first. Finishing first means less time to get from Start to Finish i.e. more meters per unit time.

Why would the best driver finish first? The best driver is more capable because he knows when to use the clutch, what gear to use in order to climb or to go downhill. In short he is more capable of driving fast because he is knowledgeable.

This is how symbols of source code createdd are used in calculating KEDE. The developer who created the most symbols of source code per unit time was most knowledgeable.

Some may say - but the race track is never the same in software development! That is not correct - the race track is the keyboard and it is always the same. Some others may say - but what if the driver is faster, but finishes in the wrong place? The Finish is set not by KEDE, but by customers, Product Owners and QAs. As explained here KEDE doesn't replace all useful metrics you use for looking into your organization as a white box.

Another analogy:

Let's imagine in front of us are two people who assemble a different model of IKEA furniture. We are told their names are Joe and Don. We are also informed that Don is a professional furniture assembler and Joe is a real novice assembling his first furniture. Our task is to tell who is Joe and who is Don just by looking at them assembling furniture.

Many of us have the frustrating experience of assembling a Billy. You know how the furniture arrived at your house, all neatly packed in a box? Yeah, that doesn't last long. Within minutes of opening the box, the contents seem to have multiplied. Suddenly, there's not enough space to stack all the pieces, and you're struggling to keep all those screws and fasteners in a neat, little pile. You pick up the instructions printed without words, using only simple illustrations, and suddenly the lack of text makes you feel extremely perplexed.

The first few steps are done and nothing can stop you. Except the next step you are doing it totally right but it's not fitting together. So you read, and then you re-read, and then you pick up the screws and try again. It's still not working. Then it's working! Nope, still not working. You hang up and look around. Your room is in shambles and random screws are rolling everywhere. Finally, the pieces screw in. It's coming together. And then you realize, on the very last step, that you're one screw short. For 10 minutes, you're on your hands and knees, going through the garbage, trying to locate the missing screw. And then you spot it. The last screw. Your key to freedom. You're sore and tired and your brain hurts, but you're done. You expected to have all your questions answered by the manual. And yet, you spent time asking yourself many more additional questions.

Having our past experience in mind while looking at the two men we can easily tell who is finding the manual informative enough, and who is asking himself many more additional questions. The former should be Done, because his training has provided him with all the knowledge needed to assemble furniture. The latter should be Joe, because he's spending a lot of time sitting on the floor with an allen wrench in one hand and the manual in the other.

Can we tell Joe or Don without looking at them while the men worked? Yes, because asking questions takes time. Existing knowledge takes less time to discover because it is in our heads. Hence, per unit time the professional should fix more screws, barrel bolts, and dowels(tacks) than a novice. Thus, by just counting at the screws two men fixed per unit time we can tell who's more efficient in discovering and applying their knowledge about assembling furniture.

This is how symbols of source code are used in calculating KEDE. The developer who created the most symbols of source code per unit time was most efficient in discovering and applying knowledge.


Is KEDE applicable to product development companies?

Context: We are not the typical outsourcing software development company that primarily writes code. Over the years we have established some very strong partnerships that bring us very close to being a product company. Hence our process is focused on creating a product employing all possible specialists - design, architecture, coding, QA, maintenance & support.

Short Answer: KEDE is applicable to product development organizations.

Long Answer: Software development organizations that sell products are still software development organizations. Designers, architects and QAs usually don't produce code, however they are there to help developers to produce it so that it meets customer's expectations. Many people overestimate how much of the knowledge discovery efficiency is a function of the skills and abilities of the individual developers and underestimate how much is determined by the system they operate in. Knowledge is a property of the system the software developer operates in. It includes the knowledge of the developer, but also the knowledge of her teammates, the Product Owner, the architect, the QA, the support, the documentation available, the applicable knowledge in StackOverflow etc.


Can KEDE replace all different metrics we use at present?

KEDE is like a thermometer. A thermometer ff used to gouge the temperature of a human treats the body as a black box. Then if the body temperature is above 37 degrees Celsius a physician will need to investigate. The physician will look into the body as a white box and make additional tests collecting additional metrics in order to find where the inflammation is and what could be its cause. Same with KEDE - it doesn't replace all useful metrics you use for looking into your organization as a white box. KEDEHub provides a thermometer but is not a physician. All the management approaches like Lean, Agile, Kanban etc. can be applied after you measure the KEDE of your organization.


So, KEDEHub is a tool for firing engineers, right?

No, KEDEHub is not a tool for firing engineers. If a company is not efficient it's not the engineers fault. It's their managers' fault. The managerial job is to create a system where the engineers can flourish, a system where expertise, solutions to problems and ideas are shared. The system must provide them with training, with enough information on a timely basis, with everything they need.

KEDEHub provides us with guidance on what needs to be changed in a knowledge worker organization in order to elevate and exploit its capability and consequently improve productivity.


What is the value of knowing KEDE?

Using KEDE is the first metric that allows for quantifying human capital of any organization, happiness and productivity of and collaboration between knowledge workers.

Knowing KEDE you can compare capability among your company's functional areas and between your company and others. You are now able to objectively and scientifically answer questions such as:

  • What is the capability of your company compared with the average level in the industry?
  • What is the capability of your team compared with the average level in the company?
  • Did the latest re-org increase the capability of your company?
  • Did the new recruits increase the capability of your team?
  • Did the Agile transformation increase the capability of your team?

KEDEHub provides us with guidance on what needs to be changed in a knowledge worker organization in order to elevate and exploit its capability and consequently improve productivity.


If our developers understand we measure KEDE will they leave us for another company?

First of all - there is no need to tell developers you measure KEDE of the organization. The knowledge discovery efficiency is of the individual developers is determined by the system they operate in. Knowledge is a property of the system the software developer operates in. If a company is not efficient it's not the engineers fault. It's their managers' fault. The managerial job is to create a system where the engineers can flourish, a system where expertise, solutions to problems and ideas are shared. The system must provide them with training, with enough information on a timely basis, with everything they need.

Secondly - only a few companies are mature enough, to measure their capability objectively. Yours is such a company, if it is a safe place, and has the courage to see the information, that KEDE Hub will reveal. That is not a small thing!


How can companies get ahead of the software engineer talent shortage?

By becoming more efficient in the utilisation of their existing talent.


How could KEDEHub improve the productivity of my company?

Software development productivity is a ratio between the outcome produced and the new knowledge discovered in order to produce the said outcome.

The outcome in the numerator can be revenue, profit etc. KEDEHub can measure the Knowledge Discovery ~Efficiency (KEDE) of your software development. Using KEDE you can calculate the Knowledge Discovered in the denominator of the productivity formula:

If the KEDE you measured is low that means developers needed a lot of new knowledge to discovere for producing the outcome. That is actually great news! You have a lot of untapped human potential!

You can use KEDEHub to monitor if there is underutilized and/or wasted human potential in your organization.

KEDEHub provides you with guidance about what needs to be changed in your organization in order to uncover and activate that untapped potential. Thus, other things being equal, if you increase your organization's efficiency, then its productivity will improve.

KEDEHub will help you start working on improving your organisation's productivity, but will not do the work for you. KEDEHub is only a tool to support process improvements by providing a target condition for your improvement efforts. The objective is to expose problems and foster creative tension in the software development organization to remove waste and increase efficiency. KEDEHub provides a thermometer but is not a physician.


Can KEDEHub be used on open source projects?

Context: We are not the typical software development company. An open source project is more like a community. People come and work for free with the idea to make the world a better place. It feels immoral to measure their capability and ask them to do better.

Short Answer: It is not immoral to use KEDE on open source projects.

Long Answer: KEDEHub allows you to group developers into teams. Hence, if your open source project has core contributors who are paid to work on it full time you can arrange them into one or more teams. All other contributors who work voluntarily and not on a regular basis you can group into a separate team and name it say "Volunteers". Then you can analyze all the other teams and never the "Volunteers".


Why is KEDEHub technology patent protected?

Context: Nowadays most of the technologies that want to be widely adopted and have impact on society are made publicly available and open source.

First of all, the math underneath KEDEhub is not patent protected. It is publicly available here and will be published in a peer-reviewed math journal. Secondly, the technology is patented in order to protect the investment in KEDEHub. The patent is available here and it describes at length how to build a machine like the calculation engine of KEDEHub. That means everybody can see how KEDEHub works.


If two developers have the same KEDE does that mean they have the same level of knowledge?

Context: Let's say we have a junior developer and an expert senior developer and when we measure them with KEDEHub they both achieve similar KEDE. Then the measurement is not correct, because the expert has to have a higher KEDE than the junior, right?

Short Answer: If any two developers have similar KEDE that doesn't mean they have the same level of knowledge. Similar KEDE means both developers have the same level of application or utilization of their own level of knowledge.

Long Answer: As per the Cambridge Dictionary, "expertise" means a high level of skill or knowledge. Expertise is the capacity of a person, their potential to do things. With KEDE we measure how much the capacity i.e. the expertise is utilized in real work, and not the capacity itself. Thus, when we say "similar KEDE" that doesn't mean both developers have the same level of knowledge i.e. the same expertise. What we say is that both developers have the same level of application or utilization of their own level of knowledge.

Example: Let's say both Joe and Don study Electrical Engineering. However, Joe is in his 3rd year and Don is in his 4th year of study. Thas, both have different levels of knowledge of Electrical Engineering. Let's say Both are taking an exam and are given a set of problems to solve for one hour. If both apply their different levels of knowledge to the maximum and solve all of the problems in the time given they will get the same grade A+.


Can we compare KEDE calculated for different programming languages?

Context: Programming languages can often be described as verbose or terse. Verbose means a language uses lots of symbols. Terse means fewer symbols. Python is not a verbose programming language. Java is a verbose programming language.

Short Answer: Yes, we compare KEDE calculated for different programming languages.

Long Answer: For detailed explanation, please read this article.


Can we compare KEDE calculated for a complex problem with KEDE calculated for a simple problem?

Context: Some may say that it is much more difficult to achieve a higher KEDE when working on a complex problem, than working on a simple problem. For instance developing embedded software to manage avionics on an aircraft compared with developing a web site.

Short Answer: Yes, we can compare KEDE calculated for a complex problem with KEDE calculated for a simple problem.

Long Answer: Here it is implied that a complex problem requires more knowledge than a simple one. That is a point we all agree with. However it is also implied that the knowledge needed for developing a web site is somehow qualitatively different from the knowledge needed for developing avionics software. Here qualitatively different means one is better than the other.

Body of knowledge (BOK) refers to the complete set of concepts, terms and skills required to work in a particular domain or industry. There are many bodies of knowledge defined. For instance, there is the Software Engineering Body of Knowledge (SWEBOK) that describes generally accepted knowledge about software engineering. We acquire knowledge by asking questions. Different domains require different numbers of questions to be answered in order to learn their body of knowledge. We may say that the more questions needed to be answered the larger a body of knowledge is. In this regard some domains have larger bodies of knowledge than other domains.

A larger body of knowledge takes more time to learn than a smaller one. The market usually values higher professions which require a larger body of knowledge. The marker also puts a higher value on knowledge that is on demand. However, a higher market valuation doesn't make a body of knowledge better i.e. qualitatively different.

We argue that all knowledge is qualitatively the same. KEDE doesn't know which body of knowledge takes longer to acquire, and which takes less. KEDE calculates the number of questions asked per symbol of source code.

Example: Let's take the Master of Science designation as another example. If Joe has MSc in Electrical Engineering and Don has MSc in Mechanical Engineering that doesn't mean Joe will be as good as Don if working as a mechanical engineer. However, MSc assures potential employers that both Joe and Don have mastered their distinct subjects at a similar level! We use KEDE to measure how efficiently people discover and apply knowledge, similarly to how MSc measures the educational level of a person.


Can we compare KEDE calculated for a junior developer with KEDE calculated for a senior developer?

Context: Let's say we have a junior developer who has a higher KEDE than an expert senior developer. Then the measurement is not correct, because the expert works on more challenging tasks and has to have a higher KEDE than the junior, right?

Short Answer: Yes, we can compare KEDE calculated for a junior developer with KEDE calculated for a senior developer.

Long Answer: As explained here in detail KEDE does not measure the level of knowledge, but if knowledge is applying in reality. Thus, we should not expect an expert to always have higher KEDE than a junior. As explained here individual KEDE depends on the difference between the level of knowledge the individual has and the level of knowledge required to do a job; Thus, if an expert had low KEDE that means they needed to acquire some missing information to add to their level of knowledge. The junior would have higher KEDE if they were assigned a task where the difference between their level of knowledge and the required level of knowledge is smaller than for the expert. That looks unfair to the expert developer only if we look at individuals and not at the software development organization as a whole. We should not try to optimize individuals but improve productivity of the organization as a whole, as explained here .

Example: Let's say Joe is a senior developer and Don is a junior. Don is assigned to simple, even routine tasks for which the difference between his level of knowledge and the required level of knowledge is minimal. Don has all the knowledge required i.e. no missing information, has no waste to remove from existing code and spends no time on non-productive activities. Thus, his KEDE should be the maximum possible value. Joe on the other hand being an expert is assigned a very challenging problem to solve for which the difference between his level of knowledge and the required level of knowledge is huge. Even if Joe has no waste to remove from existing code and spends no time on non-productive activities his KEDE will not be the maximum value. At the end Don will have higher KEDE than Joe. That may look unfair to Joe only if we look at individuals and not at the software development organization as a whole. Joe's manager knows that Joe is more knowledgeable than Don and assigns Joe to the challenging task. Thus, the total missing information for the organization is minimized. The result is that the average KEDE for the organization is maximized.


Can we compare KEDE calculated for a developer, who develops new code, with KEDE calculated for a support developer, who fixes defects?

Context: Let's say we have two developers - one, who develops new code, and a support developer, who fixes defects. The developer, who works on new features, will produce a lot of code. The developer who fixes defects will produce much less code because fixing defects requires a lot of testing and most of the time only few small changes in the existing code. Thus, his KEDE will be much lower than the KEDE of the developer, who works on new features. Then the measurement is not correct, right?

Short Answer: Yes, we can compare KEDE calculated for a developer, who develops new code, with KEDE calculated for a support developer, who fixes defects.

Long Answer: As explained here individual KEDE depends not only on the difference between the level of knowledge the individual has and the level of knowledge required to do a job, but also on the amount of existing code removed; Thus the support developer will definitely have a lower kEDE than the new features developer. That looks unfair to the support developer only if we look at individuals and not at the software development organization as a whole. The reason for the support developer to fix defects is that there are defects in the first place. The more defects the more total KEDE for the organization will fall. KEDE will properly show that there is a quality assurance problem for the organization to solve.


How can I use KEDEHub to improve productivity of my software development organization?

From the KEDE formula it follows that to improve individual KEDE we need to do the following:

  1. Decrease the difference between the level of knowledge the individual has and the level of knowledge required to do a job;
  2. Decrease the amount of waste the individual removes while doing the job;
  3. Decrease the amount of time wasted on non-productive activities;

If we want to make the organization more productive, then the average missing information for the entire organization needs to be minimized. That requires such an allocation of tasks, so that each of the members has minimum missing information to acquire. That's why we assign juniors to easy tasks and seniors to challenging problems.

Here comes the question: how to find out the missing information for an organization? You can read a detailed description how to do it on a software development project. Here is an article presenting the general approach.


Does the length of the program affect KEDE?

Context: When developing embedded software developers need to optimize for the length of the source code. The less symbols of source code created the better. Some may say that shows KEDE is not applicable to embedded software because KEDE depends on the number of symbols of source code created. Less symbols of source code created will achieve lower KEDE even though it may be very time consuming to achieve that small code size.

Short Answer: Embedded systems' KEDE is lower because such systems have a higher density of knowledge than business systems - we have to learn more to develop them, so the knowledge-per-symbol of source code is higher and the number of symbols created is usually lower.

Long Answer: For detailed explanation, please read this article.


How will auto-generated code affect KEDE calculation?

Context: Many IDEs offer class creation wizards which auto-generate not only methods, but also class files, abstract or implemented methods, place the package statement at the beginning of a class and correct imports. Coding tools like OpenAI's Codex, GitHub Copilot and CodeT5, which generate code using machine learning algorithms, have attracted increasing attention. An AI-powered tool takes natural language prompts as input (e.g., “Say hello world”) and generates code for the task it is given. When calculating KEDE we refer to the maximum possible typing speed for a human being. On the other hand, auto-generated code is created much faster than humans.

Short Answer: Generating code is much faster than typing it. That should save time. For this saved time there could be some more symbols of source code created and more tangible output i.e. working software produced. Auto-Generated code will increase KEDE only if the developer used the saved time to produce more software.

Long Answer: For detailed explanation, please read this article.


Will KEDE nudge developers not to refactor?

Context: Some may say that KEDE implies the Refactoring technique should be considered wasteful. That KEDE would nudge developers not to refactor.

Short Answer: From a knowledge discovery perspective refactoring shows that the questions developers asked were not answered properly in the first place. Some more questioning had to take place and after new knowledge was discovered the software was changed accordingly. That is a clear waste, but does not mean it is bad to do refactoring.

Long Answer: For detailed explanation, please read this article.


How would KEDE reflect the usage of Design Patterns?

Context: Let's have a junior developer, who types very fast correct code that implements the required functionality However, the junior is not aware of design patterns and unknowingly works according to the Unix principle "When in doubt, use brute force". Then we have a senior developer, who knows design patterns and with less code can implement the same functionality. Thus the junior will be less productive than the senior who with less code will get the same effect. How would KEDE reflect that difference in productivity?

Short Answer: Usinage of Design Patterns will increase KEDE only if the developer used the saved time to produce more software.

Long Answer: Patterns explicitly capture expert knowledge and design tradeoffs and make this expertise widely available. There's no need to spend a precious resource (your time) coming up with a new solution for a problem when there are tried and tested methods already available. Thus, they can accelerate the development process, which helps save time. For this saved time there could be some more symbols of source code created and more tangible output i.e. working software produced. Design patterns will increase KEDE only if the developer used the saved time to produce more software.

Example: Let's have the task of printing on a computer screen 1,000 times the sentence "This is a test!". Our junior is so novice in programming that he knows how to print on the screen, but is unaware of what a Loop is and how to implement it in Java. The junior types a line of code that prints the required sentence on the screen, then copies it and then pastes it 999 times. That he ends up with a program of 1,000 lines of code or 16,00 symbols of source code created. Our senior knows both how to print on the screen and how to implement a loop. He types one line for the loop from 0 to 999 and inside the loop one line for printing the sentence on the screen. Thus, the senior ends up with a program of 2 lines of code or 30 symbols. Since as explained here individual KEDE is calculated using the symbols of source code created then at the end of the work day the junior will have much greater KEDE than the senior. And that is correct, because the senior saved time using his knowledge, but did not return it back to the company. If the seniors would have used the saved time to produce more code he might end up with the same KEDE as the junior. Same KEDE, but with a lot more implemented functionality!

As we pointed out here KEDE is not aimed to be the single metric in software development. Thus, even with the same KEDE the senior should be rewarded for producing more functionality than the junior. Actually that's why they call them senior and junior!


Can KEDE be calculated for IT operations teams?

Context: Operations engineers install, configure, operate and evolve common infrastructure such as the network, servers, and external services e.g. the Cloud.

Short Answer: KEDEHub can be used to measure the capability of IT operations teams if they use Infrastructure as Code (IaC).

Long Answer: Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes. With IaC, configuration files are created that contain infrastructure specifications, which makes it easier to edit and distribute configurations. Version control is an important part of IaC, and the configuration files should be under source control just like any other software source code file. That means KEDEHub can be used to measure the capability of IT operations teams if they use IaC.

Automating infrastructure provisioning with IaC captures knowledge and makes this expertise widely available. There's no need to spend a precious resource (your time) to manually provision and manage servers, operating systems, storage, and other infrastructure components each time they develop or deploy an application. Thus, they can accelerate the infrastructure provisioning process, which helps save time. For this saved time there could be some more symbols of source code created and more tangible output i.e. infrastructure provisioned. Automating infrastructure provisioning will increase KEDE only if the engineers used the saved time to provision more infrastructure.


When calculating KEDE do you take into account all of the text developers produce?

Short Answer: KEDEHub will analyze only source code and documentation for it.

Long Answer: The end product of software development is the output the customer pays for. Most of the time it is source code and documentation for it. As part of their work day software developers spend a lot of time answering emails, writing content in bug tracking tools like Jora, commenting on collaboration tools like Slack and Confluence, etc. All such artefacts are means for acquiring the missing information needed to produce the output. However the means might also be oral conversations that never leave a tangible trace like email messages. Customers are not interested in all the artefacts produced as a by-product.

Thus, KEDEHub will analyze only source code and documentation for it.


How does KEDE reflect the creative nature of software development?

Short Answer: When developers create new knowledge the calculated KEDE will reflect that and will approach zero. However, most of the times when developers lack knowledge they just need to read the technical documentation.

Long Answer: Many people claim that Software Development is a creative process, because programmers can choose their solutions out of millions of possibilities that are written in dozens of programming languages, and which operate according to thousands of hardware configurations and in dozens of software platforms. In math the number of possibilities is called perplexity. Cambridge Dictionary defines "perplexity" as “a state of confusion or a complicated and difficult situation or thing.”. Using KEDE we can quantify the perplexity developers faced while working on a problem. However, it is incorrect to think that software developers need to be hugely perplexed all of the time. It is management's job to reduce their perplexity by providing training and assigning each developer to a task that matches their level of knowledge. How to deliberately reduce the degree of perplexity is presented in Managed knowledge discovery

KEDE reflects how efficiently software developers discover and apply knowledge. If the problem to be solved is unique and never solved before then it needs new knowledge to be created. Examples are scientists such as Albert Einstein and startups developing new technologies such as Bitcoin. Creating new knowledge happens when the missing information is infinite. calculated KEDE will reflect that and will approach zero.

However, not all the cases when missing information is infinite require creation of new knowledge. Most of the time when software developers claim a problem needs "creativity" they simply missed to learn, by attending training, reading technical documentation or watching videos, how other people have already solved it.


How does KEDE reflect the value I and my organization produce?

Short Answer: It doesn't. KEDE measures how efficiently the value was produced.

Long Answer: KEDE is not the indicator with capital "I". It doesn't answer all of your questions. KEDE is just one of the indicators you can use. Thus, KEDE doesn't measure the value in terms of customer satisfaction or financial profit. KEDE reflects how efficiently software developers discover and apply knowledge.

An analogy: Say we are to go on a short vacation with friends or family. Our desired outcome is to go to a place in the mountains to enjoy recreational activities. It is very important to pick a nice place for the vacation. The better the place the more value we'll get. We shall travel by car. No matter the value we get out of the vacation the car will consume a certain amount of fuel. It is useful and very practical to spend as little fuel as possible. The less fuel consumed the more efficient our trip would be. Even if the outcome is that we didn't really enjoy the vacation.

What would be the equivalent to fuel consumption in knowledge work in general and software development in particular? Software development is a process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer.

Cars run on fuel. Software development runs on knowledge.

We do innovative work - how could we achieve highest possible engineering efficiency?

Context Our company is constantly inventing stuff which is patentable. Hence, by default our existing knowledge is always less than the maximum possible. Our KEDE will always be below industry average. That however, is not fair!

Short Answer: There is no requirement to always compare yourselves to industry average. You can compare with companies like yours or with yourself from the past quarter.

Long Answer: Indeed, there are software development companies that develop innovative technologies eligible for patent protection. Such technologies vill for sure have low engineering efficiency and low WHERE. Hovejer, not all source code of cutting edge technology are patent eligible. Most of it should be something somebody else already created. Those somebody most probably will be part of the same company. Thus, if the patented knowledge is properly managed, shared and applied inside an innovative company then the overall engineering efficiency should be stable and even have a positive trend upwards.

An analogy: Envision KEDEHub as a scale, a weighing machine. When using it you may be interested in the absolute value of your weight. But most of the time you use it to see how your weight is changing. If you gain some weight you take action to lose it. Use KEDEHub this way - to manage your capability to always improve compared to the previous day.


Should we measure the capability of individual developers or of teams?

Context Let's say we have two developers. One is a junior, doing routine, well known work. The other is a senior doing innovative work. Senior will always have a lower KEDE than the junior. And that means KEDEHub will force us to favour routine over innovative work.

Short Answer: You should not measure individual capability. You should always measure the capability of an organization - be it a team, a project or a company.

Long Answer: Many people overestimate how much of the knowledge discovery efficiency is a function of the skills and abilities of the individual developers and underestimate how much is determined by the system they operate in. Knowledge is a property of the organization the software developer operates in. It includes the knowledge of the developer, but also the knowledge of her teammates, the Product Owner, the architect, the QA, the support, the documentation available, the applicable knowledge in StackOverflow etc. Designers, architects and QAs usually don't produce code. However, they are there to help developers to produce it so that it meets customer's expectations. Thus, you should not measure individual capability. You should always measure the capability of an organization - be it a team, a project or a company.


How does KEDE account for developers' happiness?

Context KEDE seems to look at software developers as "coding machines'". That feels like KEDE excludes any considerations about job satisfaction and pursuit of happiness.

Short Answer: KEDE can be used to measure developer happiness. That is achieved by assuming happiness at work coincides with a developer being in a state of Flow

Long Answer: As explained here we can measure after the work was finished, the knowledge discovered to finish the work. The knowledge discovered is measured using Knowledge Discovery Efficiency (KEDE). Thus from KEDE we can evaluate whether a developer's abilities and work complexity were in balance.

The less knowledge needed to be discovered the happier the developer. However, it should be greater than zero.

How is KEDE related to the concept of "Value of information"?

Context It is argued that in the analysis of IT investments we emphasizes development costs. There are a lot of “software metrics” firms that focus on measuring development costs, to the exclusion of measuring value. They say we should take what we would have spent on software metrics and focus it on researching the system's benefits, how quickly people will start using the system, how much it will be used and what the risk of cancellation is. To make the best investment decisions, IT management must learn how to compute the value of information, and start modeling utilization and cancellation in cost-benefit arguments.

Short Answer: KEDE has no relations whatsoever to the concept of "Value of information". At the same time KEDE is used in the denominator of the software development productivity formula. The value delivered by the IT investment is in the numerator of the formula.

Long Answer: An Epistemic Action is any action aimed at acquiring knowledge from the world. Actions could be any act of active perception, monitoring, checking, testing, ascertaining, verifying, experimenting, exploring, enquiring, giving a look to, etc. Epistemic Actions are directed either to reduce perplexity (one or more of its dimensions) or to evaluate new information. Evaluating new information has been extensively investigated in economics. There it is referred to as "Value of information" in the sense of “how much an agent is disposed to pay for obtaining that information?”. In that approach a way to calculate the value of information is given with respect to utility functions. An example would be, how much you'd pay for the following information: “Each of the houses in this city costs one million dollars”.

Using KEDE we are interested only in epistemic actions directed to reduce perplexity below a given threshold before making a decision or taking action. How much would that cost is the topic covered by "Value of information".


How is KEDE related to the concept of "Lines of Code"?

Context KEDE feels like a fancy name for "Lines of Code" (LoC).

Short Answer: KEDE has no relations whatsoever to the concept of "Lines of Code". A LoC count assesses the amount of paper a software system would consume if printed out. A KEDE value assesses the amount of knowledge, quantified in bits of information, that was discovered during the course of the system development.

Long Answer: The only similarity between KEDE and LoC is that in order to calculate both some source code attribute is counted. For LoC that is the lines of source code. For KEDE the symbols of source code are counted.

Then there is a world of differences as presented in the below table:

Lines of Code KEDE

LoC is sizing the amount of paper a software system would consume if its source code printed out.

KEDE assesses the amount of knowledge, quantified in bits of information, that was discovered during the course of the system development.

Lines of Code (LoC) assesses the “size” of a system by counting how many source lines were created.

KEDE infers the knowledge discovered by:

  1. counting how many symbols of source code were created.
  2. considering the maximum possible typing speed
  3. considering the capacity of the cognitive control of the human brain

LoC doesn't support comparisons across contexts, programming languages and applications.

KEDE supports comparisons across contexts, programming languages and applications.

LoC can be a useful predictor of software quality.

KEDE allows for quantifying human capital of an organization, happiness and productivity of and collaboration between knowledge workers.


It looks like KEDE favours developers writing more code instead of smart code?

Context KEDEHub is nothing more than a way for developers to pump out more low-quality code faster, rather than putting in the effort to write smart, effective solutions. Just look at this simple case:

  1. Junior programmer given a problem. Immediately begins coding and codes for 1 hour straight, never stopping.
  2. Senior programmer given the same problem, thinks for 59 minutes then codes for 1 minute. Solves the same problem.
Who is more productive?

Short Answer: KEDE doesn't favor developers who write more code over those who write smart code. More detailed explanation can be found here along with a numerical example.

Long Answer: KEDE does not measure software development productivity, which is a ratio between the outcome produced and the new knowledge discovered in order to produce the said outcome. The outcome in the numerator can be revenue, profit etc.

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 open interval (0,100), the higher the KEDE, the higher the productivity assuming the outcome has not changed.

It's worth noting that a developer or team with a higher KEDE score does not necessarily mean that their code is better, or that their productivity is higher. Even if a developer has a high KEDE, but low outcome value, their productivity will still be low.

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

More detailed information on how to measure productivity in software development can be found here along with a numerical example.