6 ms·

The only people that screwed it up are the ones that monetized it. They made it a) rigid based on their definition b) defined themselves as experts in making

by __abc 15y ago

The only people that screwed it up are the ones that monetized it. They made it a) rigid based on their definition b) defined themselves as experts in making teams agile based on their rigid definition c) charged for it PS. These same guys, once they couldn't squeeze anymore blood out of the Agile stone, moved onto a new marketing term, "craftsmanship". They now charge the same clients, even more money, to teach them this "new way of doing it ..... right". Plus, they make a mint on the books they hastily write and push out. I eagerly anticipate that successor to Craftsmanship.

viggity 15y ago
I disagree that craftsmanship is a replacement for agile. To me, being a software craftsman is more about how you write and structure code. Agile is about figuring out what the end product should be and how you get there.
- __abc 15y ago
  I don't mean to imply they are the same. I'm reflecting on how the same "agile experts that sell/sold their services" quickly abandoned selling that and moved onto selling "craftsmanship" once their Agile well dried up. cough Bob Martin cough cough Object Mentor cough
wpietri 15y ago
Depends on who you're talking about here. Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. I'm not sure about who's cropped up lately, though. Also, it's very, very rare for somebody to make a mint on a software book. I've talked with a number of authors, and their universal view is that writing code pays much better than writing a book. You do it because you have something to say, not because you want to get rich.
- jdlshore 15y ago
  Definitely matches my experience. And let me just leave this here... http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.htm...
- Silhouette 15y ago
  > Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. Unfortunately, you can be totally sincere in your good intentions, and yet still repeatedly be wrong. When you are a high profile figure who presumes to advise others on the best ways to do their job, that makes you a liability. It's a shame. Some of Bob Martin's earlier work exploring OO and the SOLID principles was quite decent stuff. But I think it's obvious at this point that he and several of his colleagues at Object Mentor have collectively lost the plot.
  - wpietri 15y ago
    Could be. I guess I'm not aware of the repeated wrongness on ObjectMentor's part. Got links? The big problems I saw, though, came from people who weren't particularly sincere. They were happy to sell whatever large companies were buying. E.g., two-day "Scrum Master" courses and a splash of Agile holy water to bless whatever top-down idiocy a company was already engaging in.
    - Silhouette 15y ago
      At this point, a comprehensive critique of Object Mentor would be more a case of writing a book than posting a few links. However, in the interests of not attacking them completely without justification: - Object Mentor are big advocates of XP. The fundamental principle of XP is that a certain practice is good, then doing more of it must be better. There is no logic in that position at all, and it doesn't stand up to even cursory criticism. Moreover, if XP is as superior to other processes as the typical advocacy quotes and statistics imply, how come organisations using XP aren't consistently reporting dramatically better measurable results and how come so few software development groups have chosen to adopt it? Sooner or later, people notice that the emperor has no clothes. (I suspect this is why we now have Software Craftsmanship: it's a new positive-sounding but conveniently meaningless marketing term to pitch to clients.) - Bob Martin has repeatedly stated that anyone who doesn't do TDD is unprofessional. Safety-critical software is typically not developed using TDD; in fact, formal methods, BUFD, and other very much not Agile processes are often used in such fields. - Michael Feathers redefined the term "legacy code" in terms of unit tests. There are decades of research studying what actually causes a project to decay to the point that it is difficult to maintain and update. To my knowledge, a lack of unit tests has not yet been cited as a causal factor by any paper on the subject. (FWIW, I do think Feathers' book on the subject offered some interesting and worthwhile ideas, I just don't accept his premise that having unit tests is what defines whether code is legacy or not for practical maintenance/project management purposes. I think when you try to co-opt an ill-defined but commonly understood term and give it a formal definition that is very different to the mainstream concept, you lose some credibility.) - Brett Schuchert, a man writing a book on C++, managed to make "Hello, world" take five source files and a makefile totalling nearly 100 lines, using TDD of course. - Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to understanding the problem and how you're going to solve it. - From a post on the Object Mentor blog, Brett Schuchert apparently advocates pair programming based on a 1975 study of something involving two-person teams, a ten-year-old study of university students, and a couple of links to secondary sources. The original research for almost every one of the primary sources he appeals to either directly or indirectly is no longer available at the cited links less than 18 months later. - Bob Martin thinks there are no more new kinds of programming language left to find. That's roughly on par with equating Haskell and Brainfuck because they're both Turing complete, and shows a complete lack of awareness of the state of the art. - When it comes to the amount of up-front design and formal architecture that makes sense for a project, the amount of retconning in recent comments from the TDD guys is laughable. There was a particular interview featuring Bob Martin and Jim Coplien a couple of years back that was almost painful to watch. I could go on, but if that lot doesn't paint a clear enough picture for anyone reading this, I don't have a powerful enough Kool-Aid antidote to help them. I do agree with you about the insincerity. That's worse in theory, but unfortunately it's probably no less damaging in practice. Edit: Here are few links to support some of the points above. http://www.infoq.com/interviews/coplien-martin-tdd http://www.infoq.com/interviews/coplien-martin-tdd http://skillsmatter.com/podcast/agile-testing/bobs-last-language http://skillsmatter.com/podcast/agile-testing/bobs-last-lang... http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku... http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp http://blog.objectmentor.com/articles/2010/11/09/info-please-tdd-and-pair-programming http://blog.objectmentor.com/articles/2010/11/09/info-please...

by __abc 15y ago

viggity 15y ago

I disagree that craftsmanship is a replacement for agile. To me, being a software craftsman is more about how you write and structure code. Agile is about figuring out what the end product should be and how you get there.

__abc 15y ago
I don't mean to imply they are the same. I'm reflecting on how the same "agile experts that sell/sold their services" quickly abandoned selling that and moved onto selling "craftsmanship" once their Agile well dried up. cough Bob Martin cough cough Object Mentor cough

wpietri 15y ago

Depends on who you're talking about here. Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. I'm not sure about who's cropped up lately, though. Also, it's very, very rare for somebody to make a mint on a software book. I've talked with a number of authors, and their universal view is that writing code pays much better than writing a book. You do it because you have something to say, not because you want to get rich.

jdlshore 15y ago
Definitely matches my experience. And let me just leave this here... http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.htm...
Silhouette 15y ago
> Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. Unfortunately, you can be totally sincere in your good intentions, and yet still repeatedly be wrong. When you are a high profile figure who presumes to advise others on the best ways to do their job, that makes you a liability. It's a shame. Some of Bob Martin's earlier work exploring OO and the SOLID principles was quite decent stuff. But I think it's obvious at this point that he and several of his colleagues at Object Mentor have collectively lost the plot.
- wpietri 15y ago
  Could be. I guess I'm not aware of the repeated wrongness on ObjectMentor's part. Got links? The big problems I saw, though, came from people who weren't particularly sincere. They were happy to sell whatever large companies were buying. E.g., two-day "Scrum Master" courses and a splash of Agile holy water to bless whatever top-down idiocy a company was already engaging in.
  - Silhouette 15y ago
    At this point, a comprehensive critique of Object Mentor would be more a case of writing a book than posting a few links. However, in the interests of not attacking them completely without justification: - Object Mentor are big advocates of XP. The fundamental principle of XP is that a certain practice is good, then doing more of it must be better. There is no logic in that position at all, and it doesn't stand up to even cursory criticism. Moreover, if XP is as superior to other processes as the typical advocacy quotes and statistics imply, how come organisations using XP aren't consistently reporting dramatically better measurable results and how come so few software development groups have chosen to adopt it? Sooner or later, people notice that the emperor has no clothes. (I suspect this is why we now have Software Craftsmanship: it's a new positive-sounding but conveniently meaningless marketing term to pitch to clients.) - Bob Martin has repeatedly stated that anyone who doesn't do TDD is unprofessional. Safety-critical software is typically not developed using TDD; in fact, formal methods, BUFD, and other very much not Agile processes are often used in such fields. - Michael Feathers redefined the term "legacy code" in terms of unit tests. There are decades of research studying what actually causes a project to decay to the point that it is difficult to maintain and update. To my knowledge, a lack of unit tests has not yet been cited as a causal factor by any paper on the subject. (FWIW, I do think Feathers' book on the subject offered some interesting and worthwhile ideas, I just don't accept his premise that having unit tests is what defines whether code is legacy or not for practical maintenance/project management purposes. I think when you try to co-opt an ill-defined but commonly understood term and give it a formal definition that is very different to the mainstream concept, you lose some credibility.) - Brett Schuchert, a man writing a book on C++, managed to make "Hello, world" take five source files and a makefile totalling nearly 100 lines, using TDD of course. - Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to understanding the problem and how you're going to solve it. - From a post on the Object Mentor blog, Brett Schuchert apparently advocates pair programming based on a 1975 study of something involving two-person teams, a ten-year-old study of university students, and a couple of links to secondary sources. The original research for almost every one of the primary sources he appeals to either directly or indirectly is no longer available at the cited links less than 18 months later. - Bob Martin thinks there are no more new kinds of programming language left to find. That's roughly on par with equating Haskell and Brainfuck because they're both Turing complete, and shows a complete lack of awareness of the state of the art. - When it comes to the amount of up-front design and formal architecture that makes sense for a project, the amount of retconning in recent comments from the TDD guys is laughable. There was a particular interview featuring Bob Martin and Jim Coplien a couple of years back that was almost painful to watch. I could go on, but if that lot doesn't paint a clear enough picture for anyone reading this, I don't have a powerful enough Kool-Aid antidote to help them. I do agree with you about the insincerity. That's worse in theory, but unfortunately it's probably no less damaging in practice. Edit: Here are few links to support some of the points above. http://www.infoq.com/interviews/coplien-martin-tdd http://www.infoq.com/interviews/coplien-martin-tdd http://skillsmatter.com/podcast/agile-testing/bobs-last-language http://skillsmatter.com/podcast/agile-testing/bobs-last-lang... http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku... http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp http://blog.objectmentor.com/articles/2010/11/09/info-please-tdd-and-pair-programming http://blog.objectmentor.com/articles/2010/11/09/info-please...