3 ms·

The problem with software development is it is just a very broad field. When someone talks about programming, he/she usually talk about some specific kind of pr

by caustic 16y ago

The problem with software development is it is just a very broad field. When someone talks about programming, he/she usually talk about some specific kind of programming. You see, there are many programming worlds, like system programming, middleware/framework programming, multimedia/game programming, embedded devices programming, business applications development and so on. These are very different and require different skill sets. One will have hard time transitioning from writing dating sites in PHP to writing high-performant web servers, from writing SQL queries to designing database engines. I am convinced that Agile is implicitly related to business application development, and when someone is saying he/she is using Agile methodology, they most likely develop web applications for enterprises. And probably this is the most widespread niche today. But frankly speaking, I don't think this is not the most challenging work for programmers. Been there, done that. But I am yet to see Agile evangelist who clearly states what kind of projects Agile is appropriate for. They all speak about software development in general without making distinction, as if Linux kernel or Java virtual machine or Ruby on Rails framework should be developed with their methodology. Certainly you can come up with many more examples of successfull hi-tech projects that didn't use Agile. Ironically, these projects is what makes Agile possible at all. Millions of man-haours were invested in development of operating systems, databases, virtual machines, libraries, middleware frameworks, programming languages, protocols and so on and on. Agile developers take all this as granted and try to teach everyone else how to do software development. Or thise evangelists simply have too narrow scope, then this ignorance annoying. Does Agile work for software projects that require heavy engineering? I don't think so.

philwelch 16y ago
Your comment reminds me of this: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... It's a discussion of two people, Peter Norvig and a TDD enthusiast, both building a Sudoku solver. Norvig takes a no-nonsense AI approach and the TDD enthusiast flails for five blog posts without getting anywhere. To me, the moral of the story isn't to mock TDD, but to point out that different problems require different approaches. TDD can't be naively applied to an algorithmic problem the way it can be applied to a nuts-on-bolts web app, for instance.
deleted 16y ago
[deleted]

by caustic 16y ago

philwelch 16y ago

Your comment reminds me of this: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... It's a discussion of two people, Peter Norvig and a TDD enthusiast, both building a Sudoku solver. Norvig takes a no-nonsense AI approach and the TDD enthusiast flails for five blog posts without getting anywhere. To me, the moral of the story isn't to mock TDD, but to point out that different problems require different approaches. TDD can't be naively applied to an algorithmic problem the way it can be applied to a nuts-on-bolts web app, for instance.

deleted 16y ago

[deleted]