Comments on: Code Reads #13: “The Inevitable Pain of Software Development” http://www.wordyard.com/2007/10/31/inevitable-pain/ Technology, politics, culture Tue, 16 Mar 2010 18:43:15 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: David Carlton http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1117 David Carlton Mon, 05 Nov 2007 05:49:00 +0000 http://www.wordyard.com/?p=1406#comment-1117 I wasn't too impressed with the paper. To the extent it is saying that no way of programming is perfect, big whoop; this doesn't distinguish programming from anything else in the world. Pointing out the flaws in different methods is not so banal, but to the extent that it leaves the impression that all flaws are equal (which is the sense I get from the Conclusion), I disagree. (I also agree with John Dougan's comment that it's useful to, for example, distinguish pain points that arise from fundamental impossibilities than pain points that arise from other areas.) The one bit in the paper that's not so vacuous is the claim that the pain points all come from requirements issues. This is interesting, and perhaps computer science curricula should spend more time talking about that and less time talking about, say, algorithms, but it's also not news: the methodologies mentioned in the paper generally try to attack that issue head-on, after all. I wasn’t too impressed with the paper. To the extent it is saying that no way of programming is perfect, big whoop; this doesn’t distinguish programming from anything else in the world. Pointing out the flaws in different methods is not so banal, but to the extent that it leaves the impression that all flaws are equal (which is the sense I get from the Conclusion), I disagree. (I also agree with John Dougan’s comment that it’s useful to, for example, distinguish pain points that arise from fundamental impossibilities than pain points that arise from other areas.)

The one bit in the paper that’s not so vacuous is the claim that the pain points all come from requirements issues. This is interesting, and perhaps computer science curricula should spend more time talking about that and less time talking about, say, algorithms, but it’s also not news: the methodologies mentioned in the paper generally try to attack that issue head-on, after all.

]]> By: hakdora » Blog Archive » Code Reads #13: “The Inevitable Pain of Software Development” http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1115 hakdora » Blog Archive » Code Reads #13: “The Inevitable Pain of Software Development” Sun, 04 Nov 2007 02:01:37 +0000 http://www.wordyard.com/?p=1406#comment-1115 [...] here Filed under: building [...] [...] here Filed under: building [...]

]]> By: John Dougan http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1116 John Dougan Thu, 01 Nov 2007 21:46:55 +0000 http://www.wordyard.com/?p=1406#comment-1116 My only real problem with this paper is that it doesn't provide enough distinctions between the kinds of pain points. Some pain points exist because you are trying to do something fundamentally impossible (trying to capture all of the requirements in advance). Other pain points are more because of human nature (letting smaller refactorings go until you have to do a large painful one). I'm sure the readers here could come up with their own classifications. Not all pain points are created equal and I'd rather have the some types of pain over other types of pain. My only real problem with this paper is that it doesn’t provide enough distinctions between the kinds of pain points. Some pain points exist because you are trying to do something fundamentally impossible (trying to capture all of the requirements in advance). Other pain points are more because of human nature (letting smaller refactorings go until you have to do a large painful one). I’m sure the readers here could come up with their own classifications. Not all pain points are created equal and I’d rather have the some types of pain over other types of pain.

]]> By: Dan Bernier http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1119 Dan Bernier Thu, 01 Nov 2007 17:35:23 +0000 http://www.wordyard.com/?p=1406#comment-1119 Jack W. Reeves' essay, 'What Is Software Design?' suggests that all programming is a design activity. Design is about creating a solution, and trading off between conflicting goals and constraints. Understanding those trade-offs, and what they mean, takes vision and clarity, and creating something new takes courage. A software methodology is supposed to ease the job of making software, to remove the pains from the process, but I don't know if you can remove the pain from design and creation. "There cannot be any significant change in programming until someone figures out how to deal, with a lot less pain, with the relentless change of requirements and all of its ripple effects. Perhaps, we have to accept that development is an art and that no amount of systematization will make it less so." We always ask that question: is software engineering, or art? It's practical, like engineering, but requires creativity and flexibility, like art. Maybe design is mid-way between engineering and art, and software is all design. Maybe we live with the pains. Thanks for the early Dijkstra Code Reads...they were my introduction to his writings. I'd like to suggest 'What is Software Design?', I think it'd make a great Code Reads. http://www.developerdotstar.com/mag/articles/reeves_design_main.html Jack W. Reeves’ essay, ‘What Is Software Design?’ suggests that all programming is a design activity. Design is about creating a solution, and trading off between conflicting goals and constraints. Understanding those trade-offs, and what they mean, takes vision and clarity, and creating something new takes courage. A software methodology is supposed to ease the job of making software, to remove the pains from the process, but I don’t know if you can remove the pain from design and creation.

“There cannot be any significant change in programming until someone figures out how to deal, with a lot less pain, with the relentless change of requirements and all of its ripple effects. Perhaps, we have to accept that development is an art and that no amount of systematization will make it less so.”

We always ask that question: is software engineering, or art? It’s practical, like engineering, but requires creativity and flexibility, like art. Maybe design is mid-way between engineering and art, and software is all design. Maybe we live with the pains.

Thanks for the early Dijkstra Code Reads…they were my introduction to his writings. I’d like to suggest ‘What is Software Design?’, I think it’d make a great Code Reads.

http://www.developerdotstar.com/mag/articles/reeves_design_main.html

]]> By: Cléo Saulnier http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1118 Cléo Saulnier Thu, 01 Nov 2007 14:31:57 +0000 http://www.wordyard.com/?p=1406#comment-1118 I recently wrote an article debunking the No Silver Bullet paper. It's long so be warned. http://my.opera.com/Vorlath/blog/2007/10/28/no-silver-bullet-debunked More important than that is how Berry misquoted the NSB paper. My reply talks about that here. http://my.opera.com/Vorlath/blog/2007/11/01/code-reads-13 Abstract: My biggest complaint is that Berry doesn't realise that most of what he says applies to all fields. Like what Scott quoted above: "However, for any new problem, where the excitement of innovation is, there is no hope of avoiding relentless change as we learn about the domain, the need for artistry, and the pain." These things are not what makes software different. They apply everywhere. His paper is like this all over the place. Sorry, but he completely misses the boat on this one. I recently wrote an article debunking the No Silver Bullet paper. It’s long so be warned.

http://my.opera.com/Vorlath/blog/2007/10/28/no-silver-bullet-debunked

More important than that is how Berry misquoted the NSB paper. My reply talks about that here.

http://my.opera.com/Vorlath/blog/2007/11/01/code-reads-13

Abstract: My biggest complaint is that Berry doesn’t realise that most of what he says applies to all fields. Like what Scott quoted above:

“However, for any new problem, where the excitement of innovation is, there is no hope of avoiding relentless change as we learn about the domain, the need for artistry, and the pain.”

These things are not what makes software different. They apply everywhere. His paper is like this all over the place. Sorry, but he completely misses the boat on this one.

]]> By: Brian Slesinsky http://www.wordyard.com/2007/10/31/inevitable-pain/comment-page-1/#comment-1120 Brian Slesinsky Thu, 01 Nov 2007 06:42:16 +0000 http://www.wordyard.com/?p=1406#comment-1120 Maybe part of the answer is to make the painful parts more fun? Thanks to improvements in tools, writing tests first and refactoring are much less painful than they used to be, at least in some environments. Maybe part of the answer is to make the painful parts more fun? Thanks to improvements in tools, writing tests first and refactoring are much less painful than they used to be, at least in some environments.

]]>