Frequently Asked Questions

What is KEDE?

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

KEDE quantifies the knowledge software developers didn't have prior to starting a task, since it is this lack of knowledge that significantly impacts developer happiness and the time and effort required.

Where H is the average 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 quantifies the knowledge discovered i.e. the difference between required knowledge and prior 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.

We would expect KEDE of 20 for an expert full-time software developer, who mostly applies prior 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: While it may seem that KEDE is simply measuring typing speed, it's actually much more nuanced. KEDE infers the number of questions asked using the number of symbols of source code contributed according to 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.

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, had fewer questions about what to do and how to do it - thus was most efficient in discovering and applying knowledge.

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. Prior 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.

---

Why should we trust KEDE? Is there any proof that it works?

KEDE is based on well-established principles from Information Theory and cognitive psychology. It's a patented technology that has been tested and validated in various settings. We also provide case studies demonstrating how it has successfully measured software development practices in different organizations.

Our developers are concerned about privacy and surveillance. Does KEDE intrude on their work?

KEDE respects developer privacy. It measures knowledge discovery at a high level, without tracking individual actions or keystrokes. The goal is to understand knowledge flow and growth, not to monitor individual activities.

We already have agile processes and project management tools in place. How does KEDE add value?

KEDE doesn't conflict with Agile, Kanban, or any traditional management methodologies. KEDE can be seen as a complement rather than a replacement to your existing practices. While agile processes and project management tools are good for managing tasks, KEDE specifically quantifies knowledge discovery, something not explicitly captured by these methods. Understanding how knowledge flows and grows within your teams can help optimize productivity and enhance developer happiness.

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? Is it a one-size-fits-all solution?

Good question. KEDE is a unique and powerful metric, but it's not intended to replace all other metrics. It's more like a thermometer for your organization.

Consider this analogy: When a person has a fever, a thermometer is used to gauge the body temperature. If the temperature is above the normal range, a physician will need to investigate further. They might conduct additional tests, collecting more detailed metrics to locate the source of the inflammation and diagnose the cause.

Similarly, KEDE measures the overall health of your organization, treating it as a black box. If KEDE reveals an issue, you'll need to look more deeply into your organization as a white box, using additional metrics to identify and address the root cause of the problem.

So, while KEDE is an invaluable tool for understanding the overall efficiency of knowledge discovery in your organization, it doesn't replace the need for other metrics. And it certainly doesn't replace the need for management approaches like Lean, Agile, and Kanban. KEDEHub provides the thermometer, but you still need to be the physician for 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'. 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, enough information on a timely basis, and 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?

Knowing your KEDE score offers valuable insights into human capital of your organization, and it can help you gauge the happiness, productivity of and collaboration levels among your knowledge workers.

Here are a few practical ways you can utilize KEDE to gain a competitive edge:

• Comparative Analysis: KEDE enables you to compare your company's capabilities with industry averages, and even among different functional areas within your company.
• Impact Analysis: KEDE helps in evaluating the effectiveness of significant changes within your organization. Wondering whether the latest reorganization increased your company's capability? Or if the new recruits have actually boosted the capability of your team? KEDE can give you objective answers.
• Transformation Analysis: If your team has recently undergone an Agile transformation, KEDE can help you measure if the transformation has actually increased your team's capability.

In essence, KEDEHub provides you with clear 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?

Firstly, there's no need to tell developers you measure the KEDE of the organization. Knowledge discovery efficiency of 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'. 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 provides a safe environment and has the courage to see the information that KEDE Hub will reveal. That's 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?

KEDE isn't a magic bullet, but it's an invaluable tool to help you boost your company's productivity. Think of it this way: KEDE provides a baseline, a target condition for your improvement efforts. Its purpose is to expose problems and create a sense of creative tension within your organization.

This tension motivates teams to identify waste and inefficiencies in their processes, and it drives them to find innovative solutions to these problems. In this way, KEDE can guide your organization on the path toward increased productivity.

But remember, KEDE isn't a physician—it can't diagnose specific problems or prescribe treatments. That's your role. What KEDE can do is provide you with a reliable, quantifiable measurement of your organization's knowledge discovery efficiency. It's up to you to take that information and use it to drive meaningful change

---

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: No, if two developers have similar KEDE scores, it doesn't imply that they have the same level of knowledge. Rather, it suggests that both developers are applying or utilizing their respective levels of knowledge to a similar extent.

Long Answer: 'Expertise' refers to a high level of skill or knowledge, the potential capacity of a person to perform tasks. KEDE, on the other hand, measures how much of that capacity or expertise is being utilized in actual work, not the capacity itself. So, when we say 'similar KEDE,' we're not saying that both developers possess the same level of knowledge or expertise. Instead, we're saying that both developers are utilizing their respective levels of knowledge to a similar degree.

Example: Consider two students, Joe and Don, both studying Electrical Engineering. Joe is in his 3rd year, and Don is in his 4th year, so they possess different levels of knowledge about Electrical Engineering. If both were given an exam with a set of problems to solve in one hour, and both apply their differing levels of knowledge maximally to solve all the problems within the allotted time, they would receive the same grade, an A+. Their grades reflect their application of knowledge, not the extent of their knowledge.

---

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, KEDE can be compared across different programming languages. The KEDE measure is not concerned with the specific language used, but rather calculates the number of questions asked based on the number of symbols typed. The fewer questions asked per symbol typed, the higher the KEDE.

Long Answer: Imagine two teams, Team J using Java and Team P using Python. Both teams deliver a program with the same functionality in a day, but Java's verbosity results in 10,000 symbols and Python's conciseness results in 1,000 symbols. The daily KEDE for Team J would be 10, and for Team P, would be 1, suggesting Team J is ten times more efficient in knowledge discovery.

This doesn't imply Team P did less work, as 'work' here refers to the tangible output, i.e., the working software. KEDE measures knowledge work efficiency, that is, how many questions were needed to produce the output. Therefore, despite similar outputs, Team J was more efficient in knowledge discovery. KEDE reflects how well knowledge is utilized, not the amount of tangible work done. In this context, Team J was more efficient than Team P, as they needed fewer questions to produce the same output.

If Team P had spent the whole day typing instead of asking questions, they could have developed nine more such programs, resulting in a KEDE of 10, just like Team J. KEDE accurately reflects the state of the knowledge discovery process and can illuminate the untapped potential of a team J. In this example KEDE illuminated for us the unused potential of Team P.

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: It's often assumed that a complex problem requires more knowledge than a simple one, and this is generally true. However, it's not accurate to say that the knowledge needed for developing a web site is qualitatively different, or lesser, than the knowledge needed for developing avionics software.

A Body of Knowledge (BOK) refers to the complete set of concepts, terms, and skills required to work in a particular domain or industry. Different domains require different numbers of questions to be answered in order to learn their respective BOK. Some domains have larger bodies of knowledge than others, and these larger BOKs naturally take more time to learn. The market often values professions that require a larger BOK more highly, but this higher market valuation doesn't make one BOK better or qualitatively different from another.

All knowledge is qualitatively the same from the perspective of KEDE. It doesn't distinguish between bodies of knowledge that take longer to acquire and those that don't. KEDE calculates the number of questions asked per symbol of source code.

Example: To provide an analogy, consider the Master of Science (MSc) degree. If Joe has an MSc in Electrical Engineering and Don has an MSc in Mechanical Engineering, this doesn't mean that Joe will be as effective as Don if working as a mechanical engineer. However, having an MSc signals to potential employers that both Joe and Don have mastered their respective subjects to a similar level. Similarly, KEDE measures how efficiently people discover and apply knowledge, regardless of the specific domain of that knowledge.

---

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 previously explained here, KEDE doesn't measure the level of knowledge but the application of knowledge. As previously explained, KEDE doesn't measure the level of knowledge but the application of knowledge. So, it's not necessarily incorrect if a junior developer has a higher KEDE than a senior developer. As explained here individual KEDE depends on the difference between their prior knowledge level and the level of knowledge required for a task. So, if a senior developer's KEDE is lower, it means they needed to acquire some missing information for their task. A junior developer might have a higher KEDE if the gap between their knowledge and the task requirements is smaller. This might seem unfair to the senior developer, but it's important to consider the productivity of the organization as a whole, not just individuals, as explained here.

Example: For instance, consider a scenario where Joe is a senior developer and Don is a junior developer. Don is assigned simpler tasks that align closely with his prior knowledge, so his KEDE is high. Joe, being more experienced, is assigned challenging tasks that require him to learn new information, so his KEDE is lower. This might seem unfair to Joe if we only consider individual performance. However, from an organizational perspective, this setup minimizes the total missing information and maximizes the average KEDE, which is beneficial for overall productivity.

---

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 previously explained here, individual KEDE depends not only on the difference between a developer's current knowledge level and the knowledge required for a task, but also on the amount of existing code removed. Therefore, a support developer, who often deals with fixing defects and thus removing or modifying existing code, might indeed have a lower KEDE than a developer who is writing new code.

This might seem unfair to the support developer if we only consider individual performance. However, from an organizational perspective, the presence of defects in the first place lowers the total KEDE of the organization. This indicates a potential quality assurance issue that needs to be addressed. Thus, KEDE accurately reflects the state of both the individual developer and the organization as a whole.

---

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

At a high level, software development productivity is a ratio between the outcome produced and the new knowledge discovered to produce that outcome. The outcome can be quantified in various ways, such as revenue or profit.

KEDEHub allows you to measure the amount of new knowledge discovered by your developers. This forms the denominator in the productivity formula.

So, if the KEDE you measured is low, it means your developers needed a lot of new knowledge to produce the outcome. This might sound like bad news, but it's actually quite the opposite. It signifies that there's a lot of untapped human potential in your organization.

Once you've identified these areas, KEDEHub can guide you on what needs to change in your organization to uncover and activate this untapped potential. As a result, you'll see an increase in your organization's efficiency, and consequently, its productivity.

FTo improve productivity, you need to:

1. Reduce the difference between the level of knowledge the individual possesses and the level of knowledge required to do a job.
2. Minimize the amount of waste the individual encounters while doing the job.
3. Decrease the time spent on non-productive activities.

For the organization as a whole, the goal is to minimize the average missing information. This requires task allocation such that each member has minimum missing information to acquire. This is why easier tasks are assigned to junior developers and more challenging problems to seniors.

You might be wondering how to find out the missing information for an organization? For detailed steps on how to do this for a software development project, you can read this article. Here is another 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 is designed to reflect how efficiently software developers discover and apply knowledge i.e. the level of prior knowledge leveraged in problem-solving. When a problem is unique and hasn't been solved before, it requires new knowledge to be created. This is akin to pioneers like Albert Einstein or startups like Bitcoin that were developing entirely new concepts. In such cases, where the missing information is virtually infinite, the calculated KEDE will reflect that and will approach zero.

However, it's important to note that not all instances of infinite missing information necessitate the creation of new knowledge. Often, when software developers claim a problem needs 'creativity', it could be that they simply haven't learned how others have already solved it, whether that's through training, reading technical documentation, or watching videos.

---

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

Short Answer: KEDE doesn't directly measure the value you or your organization produce, but rather the efficiency in producing that value.

Long Answer: KEDE isn't an all-encompassing indicator. It's just one of many metrics you could use. It doesn't measure the value in terms of customer satisfaction or financial profit. Instead, it reflects how efficiently software developers discover and apply knowledge.

An analogy: To draw an analogy, imagine you're planning a short vacation to the mountains. The value you derive from the vacation doesn't change the fact that your car will consume a certain amount of fuel to get you there. The less fuel you consume, the more efficient your trip. That's what KEDE measures - not the quality of the vacation, but the fuel efficiency of the journey.

In the context of knowledge work and software development, think of knowledge as the fuel. Software development is a process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery. KEDE measures how efficiently you travel along that path.

For a more detailed explanation, you can read about it here.

---

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

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

Short Answer: There's no necessity to always compare yourselves to the industry average. You can compare with similar companies or track your own progress compared to previous quarters.

Long Answer: It's true that companies developing innovative, patentable technologies will likely have lower engineering efficiency and KEDE scores. However, not all code for cutting-edge technology is patent eligible. Most likely, much of it is something someone else has already created, and that someone is likely part of the same company. Therefore, if the patented knowledge is properly managed, shared, and applied within the company, the overall engineering efficiency should be stable and may even trend upward.

An analogy: Think of KEDE as a scale. While you might be interested in your absolute weight, the scale is most useful for tracking changes in your weight. If you gain weight, you take action to lose it. Use KEDE the same way - to manage your capability and strive for continuous improvement."

---

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. The senior will always have a lower KEDE than the junior. And that means KEDE will force us to favour routine over innovative work.

Short Answer: It's not recommended to measure the capability of individual developers. Instead, you should always measure the capability of an organization, whether that be a team, a project, or a company.

Long Answer: It's a common misconception to overestimate how much of the knowledge discovery efficiency is a function of the individual developers' skills and abilities and underestimate how much is determined by the system they operate in. Knowledge is a property of the organization the software developer operates in. This includes the knowledge of the developer, but also the knowledge of their teammates, the Product Owner, the architect, the QA, the support, the documentation available, the applicable knowledge in StackOverflow, and so on.

While it's true that designers, architects, and QAs may not produce code, they contribute significantly to helping developers produce code that meets customer expectations. Therefore, it's not recommended to measure the capability of individual developers. Instead, you should always measure the capability of an organization, whether that be a team, a project, or a company.

So, in short, KEDE is not about favouring routine over innovative work. It's about measuring the efficiency of the knowledge discovery process within the organization as a whole.

---

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.

---

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 is not related to the concept of "Lines of Code" (LoC). LoC measures the volume of a software system as if printed on paper[1], while KEDE evaluates the amount of knowledge, quantified in bits of information, discovered during the development process.

Long Answer: The main similarity between KEDE and LoC lies in the act of counting specific attributes of source code. LoC counts lines, whereas KEDE counts symbols in the code.

For instance, LoC takes a string of symbols and divides it into logical groups. Take the string "for each x in list_of_x: x=x+1 print('x=',x)". It can be divided into three logical groups: "for each x in list_of_x:", "x=x+1", and "print('x=',x)". LoC suggests that the number of these groups carries specific significance when measuring developer productivity.

Contrastingly, KEDE approach would take the same string "for each x in list_of_x: x=x+1 print('x=',x)" in its entirety and count the total number of symbols, including spaces. From this count, using the KEDE theorem, we can determine how many bits of information the developer had to acquire to produce this string.

Despite this basic similarity, KEDE and LoC are significantly different in their methodology and what they measure. Let's examine a comparison:

Lines of Code	KEDE
LoC measures the "size" of a system by counting how many source lines were created.	KEDE infers the knowledge discovered by counting how many symbols of source code were created, considering the maximum possible typing speed and considering the capacity of the cognitive control of the human brain.
LoC doesn't consider the complexity of the problem solved with the code,	KEDE aptures the complexity by measuring the knowledge required to solve a problem as expressed in the code. Complex tasks that require a large amount of knowledge to solve will have a lower KEDE.
LoC doesn't support comparisons across contexts, programming languages, and applications. LoC is dependent on the verbosity of the programming language, with verbose languages having more lines of code for the same functionality.	KEDE supports comparisons across contexts, programming languages and applications. KEDE is language-agnostic. It does not consider the verbosity of a programming language but focuses on the quantity of knowledge discovered.
LLoC doesn't reflect the efficiency of a developer. A developer who writes concise code may have fewer lines of code than one who writes verbose code, yet they may both solve the same problem.	KEDE however, measures how efficiently a developer discovers and applies knowledge, thus reflecting their productivity.
LoC can be a useful predictor of software quality (metric of defects per KLOC)[2].	KEDE allows for quantifying human capital of an organization, happiness and productivity of and collaboration between knowledge workers.

1. P. G. Armour, Beware of counting LOC, Commun. ACM, 47, 3, 21–24, (Mar. 2004), doi: 10.1145/971617.971635

2. H. Zhang, "An investigation of the relationships between lines of code and defects," 2009 IEEE International Conference on Software Maintenance, Edmonton, AB, Canada, 2009, pp. 274-283, doi: 10.1109/ICSM.2009.5306304.

---

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. A junior programmer is given a problem. They immediately begin coding and code for 1 hour straight, never stopping.
2. A senior programmer is given the same problem, they think for 59 minutes then code 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 value of the output in the numerator can be quantified in monetary terms like revenue or profit, while 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 output remains constant.

It's important to note that a developer or team with a higher KEDE score doesn't necessarily mean that their code is better, or that their productivity is higher. Even if a developer has a high KEDE but low output value, their productivity will still be low.

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

---

Does higher efficiency in developers correlate with lower levels of happiness?

Short Answer: Indeed, KEDE's measurements suggest a somewhat counterintuitive relationship between efficiency and happiness in developers. The most efficient developers, those who require less discovery of new knowledge, may also be the most bored.

Long Answer: Generally, KEDE values less than 50 reflect an imbalance leaning towards anxiety, while values greater than 50 suggest an imbalance leaning towards boredom. In both cases, the balance is less optimal than when KEDE equals 50. This suggests that even as companies seek to optimize the efficiency of their existing talent in response to the software engineer talent shortage, they must also attend to the job satisfaction and intellectual stimulation of their developers to maintain a balanced, happy workforce.

---