Return to Answer

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

The answer by KilianFoth has implicitly replaced the word "write" by "run" in your question (maybe because he assumed that's what you really wanted to know). If he got you right, follow his answer.

However, from what you wrote in the comments, I guess the question you really wanted to ask is

Is it possible to know all possible defects in a program design before writing a single line of code

Here, the answer is still "no" - except for some very special scenarios. The reason is, high level software design artifacts, which are on a higher level of abstraction than code, are usually too informal to allow a rigorous proof of their defect-freeness. Typical design artifacts contain natural language, which cannot be rigidly tested like code. It is not even always obvious what a defect is. And even "design languages" like UML have often no strict semantics, which makes sometimes the line between correctness and incorrectness blurry.

Moreoever, when one puts also requirements under the umbrella of design and planning artifacts, it is should be clear you cannot decide if a requirement is "correct" or "incorrect", since requirements themselves are the benchmark for what is correct or incorrect.

However, that does not mean that all of this is in vain. Design artifacts and requirements can be analysed and reviewed by humans. Here systematic proofreading and walkthroughs by yourself or a second pairs of eyes is typically used for find inconsistencies or gaps in the design, or contradictions between requirements and design.

None of these techniques, however, can eliminate all potential issues, they can only lower the count. The ultimate test for a high-level design is when you start to implement parts of it in code, test that code and compare how well it maps to the requirements you want to achieve. That is why the most effective design validation technique is to implement parts in executable code, ideally in small iterative cycles, and not in a "Big-Design-Upfront".

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

The answer by @KilianFoth has implicitly replaced the word "write" by "run" in your question (maybe because he assumed that's what you really wanted to know). If he got you right, follow his answer.

However, from what you wrote in the comments, I guess the question you really wanted to ask is

Is it possible to know all possible defects in a program's design before writing a single line of code

Here, the answer is still "no" - except for some very special scenarios. The reason is, typical software design artifacts, which are on a higher level of abstraction than code, are usually too informal to allow a rigorous proof of their defect-freeness. Typical design artifacts contain natural language, which cannot be rigidly tested like code. It is not even always obvious what a defect is. And even "design languages" like UML have often no strict semantics, which makes the line between correctness and incorrectness blurry.

Moreoever, when one puts also requirements under the umbrella of design and planning artifacts, it is should be clear you cannot decide if a requirement is "correct" or "incorrect", since requirements themselves are the benchmark for what is correct or incorrect.

However, that does not mean that all of this is in vain. Design artifacts and requirements can be analysed and reviewed by humans. Here systematic proofreading and walkthroughs by yourself or a second pairs of eyes is typically used for find inconsistencies or gaps in the design, or contradictions between requirements and design.

None of these techniques, however, can eliminate all potential issues, they can only lower the count. The ultimate test for a high-level design is when you start to implement parts of it in code, test that code and compare how well it maps to the requirements you want to achieve. That is why the most effective design validation technique is to implement parts in executable code, ideally in small iterative cycles, and not in a "Big-Design-Upfront".

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

Other answers by KilianFoth and JonsH have replaced the word "write" by "run" implicitly in your question (maybe because they assumed that's what you really wanted to know, maybe because they did not read your question carefully). If they got you right, follow their answers.

However, from what you wrote in the comments, I guess the question you really wanted to ask is

Is it possible to know all possible defects in a program design before writing a single line of code

Here, the answer is still "no" - except for some very special scenarios. The reason is, high level software design artifacts, which are on a higher level of abstraction than code, are usually too informal to allow a rigorous proof of their defect-freeness. Typical design artifacts contain natural language, which cannot be rigidly tested like code. It is not even always obvious what a defect is. And even "design languages" like UML have often no strict semantics, which makes sometimes the line between correctness and incorrectness blurry.

Moreoever, when one puts also requirements under the umbrella of design and planning artifacts, it is should be clear you cannot decide if a requirement is "correct" or "incorrect", since requirements themselves are the benchmark for what is correct or incorrect.

However, that does not mean that all of this is in vain. Design artifacts and requirements can be analysed and reviewed by humans. Here systematic proofreading and walkthroughs by yourself or a second pairs of eyes is typically used for find inconsistencies or gaps in the design, or contradictions between requirements and design.

None of these techniques, however, can eliminate all potential issues, they can only lower the count. The ultimate test for a high-level design is when you start to implement parts of it in code, test that code and compare how well it maps to the requirements you want to achieve. That is why the most effective design validation technique is to implement parts in executable code, ideally in small iterative cycles, and not in a "Big-Design-Upfront".

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

The answer by KilianFoth has implicitly replaced the word "write" by "run" in your question (maybe because he assumed that's what you really wanted to know). If he got you right, follow his answer.

However, from what you wrote in the comments, I guess the question you really wanted to ask is

Is it possible to know all possible defects in a program design before writing a single line of code

Here, the answer is still "no" - except for some very special scenarios. The reason is, high level software design artifacts, which are on a higher level of abstraction than code, are usually too informal to allow a rigorous proof of their defect-freeness. Typical design artifacts contain natural language, which cannot be rigidly tested like code. It is not even always obvious what a defect is. And even "design languages" like UML have often no strict semantics, which makes sometimes the line between correctness and incorrectness blurry.

Moreoever, when one puts also requirements under the umbrella of design and planning artifacts, it is should be clear you cannot decide if a requirement is "correct" or "incorrect", since requirements themselves are the benchmark for what is correct or incorrect.

However, that does not mean that all of this is in vain. Design artifacts and requirements can be analysed and reviewed by humans. Here systematic proofreading and walkthroughs by yourself or a second pairs of eyes is typically used for find inconsistencies or gaps in the design, or contradictions between requirements and design.

None of these techniques, however, can eliminate all potential issues, they can only lower the count. The ultimate test for a high-level design is when you start to implement parts of it in code, test that code and compare how well it maps to the requirements you want to achieve. That is why the most effective design validation technique is to implement parts in executable code, ideally in small iterative cycles, and not in a "Big-Design-Upfront".

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

Other answers by KilianFoth and JonsH have replaced the word "write" by "run" implicitly in your question (maybe because they assumed that's what you really wanted to know, maybe because they did not read your question carefully). If they got you right, follow their answers.

It seems noone here answered your literal question:

Is it possible to know all possible defects in a program before I write a single line of code

For this question, the answer is trivial: it is clearly no. When there is no code, you cannot even tell if your program has a syntactical error, since there is nothing to evaluate.

Other answers by KilianFoth and JonsH have replaced the word "write" by "run" implicitly in your question (maybe because they assumed that's what you really wanted to know, maybe because they did not read your question carefully). If they got you right, follow their answers.

However, from what you wrote in the comments, I guess the question you really wanted to ask is

Is it possible to know all possible defects in a program design before writing a single line of code

Here, the answer is still "no" - except for some very special scenarios. The reason is, high level software design artifacts, which are on a higher level of abstraction than code, are usually too informal to allow a rigorous proof of their defect-freeness. Typical design artifacts contain natural language, which cannot be rigidly tested like code. It is not even always obvious what a defect is. And even "design languages" like UML have often no strict semantics, which makes sometimes the line between correctness and incorrectness blurry.

Moreoever, when one puts also requirements under the umbrella of design and planning artifacts, it is should be clear you cannot decide if a requirement is "correct" or "incorrect", since requirements themselves are the benchmark for what is correct or incorrect.

However, that does not mean that all of this is in vain. Design artifacts and requirements can be analysed and reviewed by humans. Here systematic proofreading and walkthroughs by yourself or a second pairs of eyes is typically used for find inconsistencies or gaps in the design, or contradictions between requirements and design.

None of these techniques, however, can eliminate all potential issues, they can only lower the count. The ultimate test for a high-level design is when you start to implement parts of it in code, test that code and compare how well it maps to the requirements you want to achieve. That is why the most effective design validation technique is to implement parts in executable code, ideally in small iterative cycles, and not in a "Big-Design-Upfront".