First off, when you say "better code" I'm going to assume that you mean that the general software quality of the project is better as opposed to any measure of the aesthetics of the code itself, although code that is easier to read generally results in better quality software.

One of the big area's of study in software engineering research has been to see if there is a correlation between known requirements and defects, these studies shown that adding requirements or changing requirements of a system generally results in more defects. This tends to be bore out by other studies that show a link between changing requirements and schedule and cost overrun.

The core reasoning for most of these finding boils down to knowing what is needed before hand allows for the system to be built to meet those needs and the system can be verified against those needs. This tends to work well in environments well the requirement be explicitly defined, tested, and failure is not an option.

So for at least some segments of software development it can easily be established that specifications result in better code. However, what about environments where the needs can change on a regular basis based upon business needs? In these cases it is important to note that Agile methodologies tend to be used more for internet development than for real-time, control, or systems development. Thus, Agile methodologies tend to target a different development space and we can speculate address different needs. Advocates for Agile development generally call for simple designs and refactoring as a means of ensuring that the code base does not become too complex which has been tied to software defects.

Overall, yes, foreknowledge of fixed requirements results in better code. However, when the requirements cannot be fixed due to changing business requirements, that advantage is largely irrelevant as you may not be able to fix the system requirements long enough to code a major system.

First off, when you say "better code" I'm going to assume that you mean that the general software quality of the project is better as opposed to any measure of the aesthetics of the code itself, although code that is easier to read generally results in better quality software.

One of the big areas of study in software engineering research has been to see if there is a correlation between known requirements and defects. These studies show that adding requirements or changing requirements of a system generally results in more defects. This tends to be born out by other studies that show a link between changing requirements and schedule and cost overrun.

The core reasoning for most of these findings boils down to knowing what is needed beforehand allows the system to be built to meet those needs and the system can be verified against those needs. This tends to work well in environments where the requirements can be explicitly defined and tested, and failure is not an option.

So for at least some segments of software development it can easily be established that specifications result in better code.

What about environments where the needs can change on a regular basis based upon business needs? In these cases it is important to note that Agile methodologies tend to be used more for internet development than for real-time, control, or systems development. Thus, Agile methodologies tend to target a different development space and we can speculate address different needs. Advocates for Agile development generally call for simple designs and refactoring as a means of ensuring that the code base does not become too complex which has been tied to software defects.

Overall, yes, foreknowledge of fixed requirements results in better code, but when the requirements cannot be fixed due to changing business requirements, that advantage is largely irrelevant as you may not be able to fix the system requirements long enough to code a major system.

First off, when you say "better code" I'm going to assume that you mean that the general software quality of the project is better as opposed to any measure of the aesthetics of the code itself, although code that is easier to read generally results in better quality software.

One of the big area's of study in software engineering research has been to see if there is a correlation between known requirements and defects, these studies shown that adding requirements or changing requirements of a system generally results in more defects. This tends to be bore out by other studies that show a link between changing requirements and schedule and cost overrun.

The core reasoning for most of these finding boils down to knowing what is needed before hand allows for the system to be built to meet those needs and the system can be verified against those needs. This tends to work well in environments well the requirement be explicitly defined, tested, and failure is not an option.

So for at least some segments of software development it can easily be established that specifications result in better code. However, what about environments where the needs can change on a regular basis based upon business needs? In these cases it is important to note that Agile methodologies tend to be used more for internet development than for real-time, control, or systems development. Thus, Agile methodologies tend to target a different development space and we can speculate address different needs. Advocates for Agile development generally call for simple designs and refactoring as a means of ensuring that the code base does not become too complex which has been tied to software defects.

Overall, yes, foreknowledge of fixed requirements results in better code. However, when the requirements cannot be fixed due to changing business requirements, that advantage is largely irrelevant as you may not be able to fix the system requirements long enough to code a major system.

First off, when you say "better code" I'm going to assume that you mean that the general software quality of the project is better as opposed to any measure of the aesthetics of the code itself, although code that is easier to read generally results in better quality software.

One of the big area's of study in software engineering research has been to see if there is a correlation between known requirements and defects, these studies shown that adding requirements or changing requirements of a system generally results in more defects. This tends to be bore out by other studies that show a link between changing requirements and schedule and cost overrun.

The core reasoning for most of these finding boils down to knowing what is needed before hand allows for the system to be built to meet those needs and the system can be verified against those needs. This tends to work well in environments well the requirement be explicitly defined, tested, and failure is not an option.

So for at least some segments of software development it can easily be established that specifications result in better code. However, what about environments where the needs can change on a regular basis based upon business needs? In these cases it is important to note that Agile methodologies tend to be used more for internet development than for real-time, control, or systems development. Thus, Agile methodologies tend to target a different development space and we can speculate address different needs. Advocates for Agile development generally call for simple designs and refactoring as a means of ensuring that the code base does not become too complex which has been tied to software defects.

Overall, yes, foreknowledge of fixed requirements results in better code. However, when the requirements cannot be fixed due to changing business requirements, that advantage is largely irrelevant as you may not be able to fix the system requirements long enough to code a major system.