Testing Is the Engineering Rigor of Software Development - Revision history

Kevlin: Testing is the Engineering Rigor of Software Development moved to Testing Is the Engineering Rigor of Software Development

2009-07-07T12:17:31Z

Testing is the Engineering Rigor of Software Development moved to Testing Is the Engineering Rigor of Software Development

←Older revision

Revision as of 12:17, 7 July 2009

Kevlin at 15:58, 22 November 2008

2008-11-22T15:58:15Z

←Older revision		Revision as of 15:58, 22 November 2008
Line 3:		Line 3:
	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written almost two decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.		Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written almost two decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.

-	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.	+	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building — we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.

	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing '''''is''''' the engineering rigor of software development.		Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing '''''is''''' the engineering rigor of software development.

Kevlin at 07:33, 21 November 2008

2008-11-21T07:33:01Z

←Older revision		Revision as of 07:33, 21 November 2008
Line 1:		Line 1:
	Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways.		Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways.

-	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written almost 2 decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.	+	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written almost two decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.

	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.		Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.

Nealford at 23:11, 20 November 2008

2008-11-20T23:11:33Z

←Older revision		Revision as of 23:11, 20 November 2008
Line 1:		Line 1:
-	Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways. For example, think about the building in which you currently sit, and think about how long it took to architect, design, and build it, along with the required resources. Then, think about a software project of a similar size. Yet, in the software project, if you have a small defect, it can cause the entire thing to fail in unforeseen ways. If the light-socket cover doesn't completely cover the hole, it can't cause the building to fail, but a similarly small defect in software can cause major problems. Of course, software is easier to fix than a building, but the tolerances for perfection in software are ridiculously fine. In software, we often lack a direct correlation between fault and location. If a wing falls off a plane, an engineer can start snooping around the bolts that hold the wing in place to determine what went wrong.	+	Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways.

-	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written ~~more than a decade~~ ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.	+	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written almost 2 decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.

-	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We ~~can design a new thing and build it to see how it reacts. And we~~'ve developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. ~~In fact, other~~ engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.	+	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.

-	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. ~~Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing." Implicit in this quote is the realization that testing~~ '''''is''''' the engineering rigor of software development.	+	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing '''''is''''' the engineering rigor of software development.

	By [[Neal Ford]]		By [[Neal Ford]]

Kevlin at 16:45, 12 November 2008

2008-11-12T16:45:05Z

←Older revision		Revision as of 16:45, 12 November 2008
Line 1:		Line 1:
-	Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways. For example: think about the building in which you currently sit, and think about how long it took to architect, design, and build it, along with the required resources. Then, think about a software project of a similar size. Yet, in the software project, if you have a small defect, it can cause the entire thing to fail in ~~unpredicted~~ ways. If the light-socket cover doesn't completely cover the hole, it can't cause the building to fail, but a similarly small defect in software can cause major problems. Of course, software is easier to fix than a building, but the tolerances for perfection in software are ridiculously fine. In software, we often ~~also don't have~~ a direct correlation between fault and location. If a wing falls off a plane, an engineer can start snooping around the bolts that hold the wing in place to determine what went wrong.	+	Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways. For example, think about the building in which you currently sit, and think about how long it took to architect, design, and build it, along with the required resources. Then, think about a software project of a similar size. Yet, in the software project, if you have a small defect, it can cause the entire thing to fail in unforeseen ways. If the light-socket cover doesn't completely cover the hole, it can't cause the building to fail, but a similarly small defect in software can cause major problems. Of course, software is easier to fix than a building, but the tolerances for perfection in software are ridiculously fine. In software, we often lack a direct correlation between fault and location. If a wing falls off a plane, an engineer can start snooping around the bolts that hold the wing in place to determine what went wrong.

-	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, ~~then~~ it's a good bridge. If not, well, ~~then~~ time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can ~~apply to~~ structural ~~problems~~ without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, ~~check out the article~~ [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in C++ Journal in 1992. Even though it was written more than a decade ago, it is still remarkably accurate. He ~~gives~~ a gloomy picture is this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.	+	Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in ''C++ Journal'' in 1992, is a classic. Even though it was written more than a decade ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.

-	Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.	+	Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.

-	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.	+	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing." Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.

-	[[Neal Ford]]	+	By [[Neal Ford]]
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Nealford at 17:59, 9 November 2008

2008-11-09T17:59:10Z

←Older revision		Revision as of 17:59, 9 November 2008
Line 4:		Line 4:

	Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.		Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.
-
-	[[Neal Ford]]

	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.		Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.
		+
		+	[[Neal Ford]]

Nealford at 17:58, 9 November 2008

2008-11-09T17:58:54Z

←Older revision		Revision as of 17:58, 9 November 2008
Line 4:		Line 4:

	Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.		Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.
		+
		+	[[Neal Ford]]

	Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.		Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.

Nealford: New page: Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "ha...

2008-11-09T17:58:18Z

New page: Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "ha...

New page

Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is ''not'' like many of the "hard" engineering disciplines in lots of important ways. For example: think about the building in which you currently sit, and think about how long it took to architect, design, and build it, along with the required resources. Then, think about a software project of a similar size. Yet, in the software project, if you have a small defect, it can cause the entire thing to fail in unpredicted ways. If the light-socket cover doesn't completely cover the hole, it can't cause the building to fail, but a similarly small defect in software can cause major problems. Of course, software is easier to fix than a building, but the tolerances for perfection in software are ridiculously fine. In software, we often also don't have a direct correlation between fault and location. If a wing falls off a plane, an engineer can start snooping around the bolts that hold the wing in place to determine what went wrong.

Compared to "hard" engineering, the software development world is at about the same place the bridge builders where when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, then it's a good bridge. If not, well, then time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can apply to structural problems without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, check out the article [http://www.developerdotstar.com/mag/articles/reeves_design.html What is Software Design], written by Jack Reeves in C++ Journal in 1992. Even though it was written more than a decade ago, it is still remarkably accurate. He gives a gloomy picture is this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.

Testing "hard" things is tough because you have to build it to test it, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We can design a new thing and build it to see how it reacts. And we've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. In fact, other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "we don't have time to test". A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building -- we have a tight deadline". The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.

Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what we produce. Testing alone isn't sufficient, but it is necessary. Stuart Halloway has a great quote about software quality: "In 5 years, we will view compilation as the weakest form of unit testing". Implicit in this quote is the realization that testing '''''is''''' the engineering rigor of software development.