Own (and Refactor) the Build - Revision history

Kevlin at 21:36, 10 July 2009

2009-07-10T21:36:23Z

←Older revision		Revision as of 21:36, 10 July 2009
Line 1:		Line 1:
-	It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, out of ~~either~~ a belief that they are merely an unimportant detail or a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.	+	It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, either out of a belief that they are merely an unimportant detail or from a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.

-	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.	+	One rationale for why disciplined, skilled developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.

	Build scripts written using the wrong idioms are difficult to maintain and, more significantly, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency or when a build-time configuration is wrong.		Build scripts written using the wrong idioms are difficult to maintain and, more significantly, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency or when a build-time configuration is wrong.
Line 7:		Line 7:
	Traditionally testing has been something that was always left to the "Quality Assurance" team. We now realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.		Traditionally testing has been something that was always left to the "Quality Assurance" team. We now realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple-to-execute build allows a new developer to get started quickly and easily. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding an "it works for me" conversation. Many build tools allow you to run reports on code quality, ~~allowing~~ you to sense potential problems early. By spending time understanding how to make the build yours, you can help yourself and everyone else on your team. You can focus on coding features, benefiting your stakeholders and making work more enjoyable.	+	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple-to-execute build allows a new developer to get started quickly and easily. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding an "it works for me" conversation. Many build tools allow you to run reports on code quality, letting you to sense potential problems early. By spending time understanding how to make the build yours, you can help yourself and everyone else on your team. You can focus on coding features, benefiting your stakeholders and making work more enjoyable.

-	Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code ~~and~~ are too important to be left to someone else, if for no other reason than because the application is not complete until it is built~~, and the~~ job of programming is not complete until we have delivered working software.	+	Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code. They are too important to be left to someone else, if for no other reason than because the application is not complete until it is built. The job of programming is not complete until we have delivered working software.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Kevlin at 22:18, 16 February 2009

2009-02-16T22:18:23Z

←Older revision		Revision as of 22:18, 16 February 2009
Line 1:		Line 1:
-	It is not uncommon for teams that are highly disciplined about coding practices to ~~either~~ neglect build scripts out of a belief that they are merely a unimportant detail, or a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.	+	It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, out of either a belief that they are merely an unimportant detail or a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.

	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.		One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.

Sberczuk at 22:03, 16 February 2009

2009-02-16T22:03:24Z

←Older revision		Revision as of 22:03, 16 February 2009
Line 1:		Line 1:
-	It is not uncommon for teams that are highly disciplined about coding practices to either neglect build scripts or ~~treat them as~~ a ~~black art~~. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.	+	It is not uncommon for teams that are highly disciplined about coding practices to either neglect build scripts out of a belief that they are merely a unimportant detail, or a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.

	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.		One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.

Kevlin at 11:35, 3 February 2009

2009-02-03T11:35:24Z

←Older revision		Revision as of 11:35, 3 February 2009
Line 1:		Line 1:
-	~~Often~~ teams that at highly disciplined about coding practices either neglect build scripts or treat them as a black art. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.	+	It is not uncommon for teams that are highly disciplined about coding practices to either neglect build scripts or treat them as a black art. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.

-	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages, and that the build is what creates executable artifacts for developers and end users to test and run~~; the~~ code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and ~~some~~ decisions about the build process ~~that could~~ make the code ~~(or~~ the coding ~~process)~~ simpler.	+	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler.

-	Build scripts written using the wrong idioms are difficult to maintain and, more ~~important~~, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong.	+	Build scripts written using the wrong idioms are difficult to maintain and, more significantly, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency or when a build-time configuration is wrong.

-	~~In earlier times,~~ testing ~~was~~ something that was left ~~the~~ the "Quality Assurance" team. ~~Now we~~ realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.	+	Traditionally testing has been something that was always left to the "Quality Assurance" team. We now realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple to execute build ~~makes it easy to get~~ a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to ~~detect~~ potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team, focus on coding features, benefiting your stakeholders and making work more enjoyable.	+	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple-to-execute build allows a new developer to get started quickly and easily. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding an "it works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to sense potential problems early. By spending time understanding how to make the build yours, you can help yourself and everyone else on your team. You can focus on coding features, benefiting your stakeholders and making work more enjoyable.

	Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.		Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.

Sberczuk at 22:53, 28 December 2008

2008-12-28T22:53:55Z

←Older revision		Revision as of 22:53, 28 December 2008
Line 3:		Line 3:
	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages, and that the build is what creates executable artifacts for developers and end users to test and run; the code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and some decisions about the build process that could make the code (or the coding process) simpler.		One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages, and that the build is what creates executable artifacts for developers and end users to test and run; the code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and some decisions about the build process that could make the code (or the coding process) simpler.

-	Build scripts written using the wrong idioms are difficult to maintain and, more important, improve. It is worth spending some time to understand the right way to make a change. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong~~. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work~~.	+	Build scripts written using the wrong idioms are difficult to maintain and, more important, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong.

	In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.		In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.	+	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team, focus on coding features, benefiting your stakeholders and making work more enjoyable.

	Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.		Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.

Sberczuk at 22:50, 28 December 2008

2008-12-28T22:50:43Z

←Older revision		Revision as of 22:50, 28 December 2008
Line 1:		Line 1:
-	Often teams that at highly disciplined about coding practices ~~treat~~ build scripts as a black art. ~~Projects with highly refactored code have~~ build scripts with duplication ~~that are difficult to maintain. Duplication~~ and errors ~~in the build scripts~~ cause problems of the same magnitude as those in poorly factored code.	+	Often teams that at highly disciplined about coding practices either neglect build scripts or treat them as a black art. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.

-	~~It's curious~~ why disciplined, skilled, developers treat the build as something secondary to their work~~. One rationale~~ is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These ~~reasons have their flaws~~.	+	One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages, and that the build is what creates executable artifacts for developers and end users to test and run; the code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and some decisions about the build process that could make the code (or the coding process) simpler.

-	Most software developers enjoy learning new languages, so the language difference does not ring true. The build is what creates executable artifacts for developers and end users to test and run, and since the code is useless without being built, it's inconsistent to say that the build is not code. And since the build is part of the development process, there are some decisions about the build process that could make the code (or the coding process) simpler.	+	Build scripts written using the wrong idioms are difficult to maintain and, more important, improve. It is worth spending some time to understand the right way to make a change. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.
-		+
-	Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies which can make it harder to change processes, and harder still to debug problems. Build scripts written using the wrong idioms ~~make it~~ difficult ~~for others to understand how~~ to improve ~~the build~~. ~~Whether your project is built using Maven, ANT, Rake, Make, or some other tool, it~~ is worth spending some time to understand the right way to make a change. ~~The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested.~~ "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.	+
-		+
-	One valid rationale for treating build scripts as second class entities is that tools don't support working with build scripts as well as they do "real" code. While this may be true (less so as tools improve), the build is still essential to delivering software applications.	+

	In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.		In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	Understanding the build can simplify ~~your life in other ways too~~. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.	+	Understanding the build can simplify the entire development lifecycle and reduce costs. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.

-	Learn enough of your build process to know when to make changes ~~and what the correct idioms are~~. Build scripts ''are'' code and are too important to be left to someone else.	+	Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:57, 27 December 2008

2008-12-27T22:57:15Z

←Older revision		Revision as of 22:57, 27 December 2008
Line 13:		Line 13:
	Understanding the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.		Understanding the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.

-	Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts ~~_are_~~ code and are too important to be left to someone else.	+	Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts ''are'' code and are too important to be left to someone else.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:54, 27 December 2008

2008-12-27T22:54:32Z

←Older revision		Revision as of 22:54, 27 December 2008
Line 1:		Line 1:
	Often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain. Duplication and errors in the build scripts cause problems of the same magnitude as those in poorly factored code.		Often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain. Duplication and errors in the build scripts cause problems of the same magnitude as those in poorly factored code.

-	~~One explanation for~~ why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language. Another, ~~related, rationale~~ is that the build is not really "code." Yet, most software developers enjoy learning new languages, so the language difference does not ring true. Since the build is what creates executable artifacts for developers and end users to test and run, and since the code is useless without being built, it's inconsistent to say that the build is not code.	+	It's curious why disciplined, skilled, developers treat the build as something secondary to their work. One rationale is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These reasons have their flaws.

-	~~Much like~~ code, ~~where there~~ is ~~duplication in~~ the build ~~process~~ is ~~a place where things break when~~ there are ~~inconsistencies which can~~ make ~~it harder to change processes, and harder still to debug problems~~.	+	Most software developers enjoy learning new languages, so the language difference does not ring true. The build is what creates executable artifacts for developers and end users to test and run, and since the code is useless without being built, it's inconsistent to say that the build is not code. And since the build is part of the development process, there are some decisions about the build process that could make the code (or the coding process) simpler.

-	Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build. Whether your project is built using Maven, ANT, Rake, Make, or some other tool, it is worth spending some time to understand the right way to make a change.	+	Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies which can make it harder to change processes, and harder still to debug problems. Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build. Whether your project is built using Maven, ANT, Rake, Make, or some other tool, it is worth spending some time to understand the right way to make a change. The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.

-	~~In earlier times, testing was something~~ that ~~was left the the~~ "~~Quality Assurance~~" ~~team~~. ~~Now we realize that testing~~ as ~~we code is necessary to being able to deliver value predictably. In much the same way~~, the build ~~process needs~~ to ~~be owned by the development team~~.	+	One valid rationale for treating build scripts as second class entities is that tools don't support working with build scripts as well as they do "real" code. While this may be true (less so as tools improve), the build is still essential to delivering software applications.

-	~~The build process is where everything comes together to create executable code~~ that ~~is tested by developers, built in an integration environment, and tested.~~ "~~Bugs~~" ~~can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong~~. ~~The build~~ is ~~too important~~ to ~~leave~~ to ~~someone else~~, ~~and in fact, it is~~ the ~~person developing~~ the ~~code who knows how the build should work~~.	+	In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	~~Thinking about~~ the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.	+	Understanding the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.

-	Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts ~~/are/~~ code and are too important to be left to someone else.	+	Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts _are_ code and are too important to be left to someone else.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 21:56, 27 December 2008

2008-12-27T21:56:35Z

←Older revision		Revision as of 21:56, 27 December 2008
Line 1:		Line 1:
-	~~Quite often~~ teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain, and cause ~~many~~ of the same ~~problems that the~~ poorly factored code ~~causes~~.	+	Often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain. Duplication and errors in the build scripts cause problems of the same magnitude as those in poorly factored code.

-	One explanation for ~~this~~ is that build scripts are in a different language? Yet, most software developers enjoy learning new languages.	+	One explanation for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language. Another, related, rationale is that the build is not really "code." Yet, most software developers enjoy learning new languages, so the language difference does not ring true. Since the build is what creates executable artifacts for developers and end users to test and run, and since the code is useless without being built, it's inconsistent to say that the build is not code.

-	~~Is it because~~ the build is ~~not "code"? The application won't work unless you build~~ it.	+	Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies which can make it harder to change processes, and harder still to debug problems.

-	~~Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies.~~ Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build.	+	Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build. Whether your project is built using Maven, ANT, Rake, Make, or some other tool, it is worth spending some time to understand the right way to make a change.

-	~~The build process is where everything comes together to create executable code~~ that ~~is tested by developers, built in an integration environment, and tested.~~ "~~Bugs~~" ~~can appear when an application is built with teh wrong version of a dependency, or when a build time configuration is wrong~~. ~~The build~~ is ~~too important~~ to ~~leave~~ to ~~someone else~~, ~~and in fact, it is~~ the ~~person developing~~ the ~~code who knows how the build should work~~.	+	In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.

-	A simple to execute build makes it easy to get a new developer started~~, and~~ get consistent results when multiple people are working on a project ~~(thus~~ avoiding a "works for me" conversation). Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts are code and ~~should~~ be ~~treated as such~~.	+	The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.
		+
		+	Thinking about the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.
		+
		+	Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts /are/ code and are too important to be left to someone else.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:29, 28 November 2008

2008-11-28T22:29:51Z

←Older revision		Revision as of 22:29, 28 November 2008
Line 1:		Line 1:
-	Quite often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication.	+	Quite often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain, and cause many of the same problems that the poorly factored code causes.

-	Is this ~~because~~ build scripts are in a different language? ~~Most~~ software developers enjoy learning ~~how to use~~ new languages ~~well~~.	+	One explanation for this is that build scripts are in a different language? Yet, most software developers enjoy learning new languages.

	Is it because the build is not "code"? The application won't work unless you build it.		Is it because the build is not "code"? The application won't work unless you build it.

-	Much like code, ~~duplication~~ is a build process is a place where things break when there are inconsistencies.	+	Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies. Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build.

-	The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.	+	The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested. "Bugs" can appear when an application is built with teh wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.

		+	A simple to execute build makes it easy to get a new developer started, and get consistent results when multiple people are working on a project (thus avoiding a "works for me" conversation). Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts are code and should be treated as such.

-	~~Examples: Not using correct idioms.~~	+	By [[Steve Berczuk]]

		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

-	~~Advice: Learn enough of your build process~~ to ~~know when to make changes and what the correct idioms are.~~	+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page