6 ms·

To expand on that a bit, I should mention that this question came up at a software craftsmanship meetup, after Martin had given a talk in Cambridge. (Incidental

by robin2 13y ago

To expand on that a bit, I should mention that this question came up at a software craftsmanship meetup, after Martin had given a talk in Cambridge. (Incidentally, people who had seen him speak had been very disappointed.) The only answers to "Who is Uncle Bob?" seemed to be "He's very old" and "He wrote a book". Given his schtick is to be a sage figure of comparable stature to, say, Don Knuth or Brian Kernighan, I don't think that's good enough. (I missed Martin's talk because it clashed with one by Herman Hauser. Industry pioneer vs methodology salesman wasn't much of a contest for me.) I the interests of full disclosure, I should probably mention that I've had an encounter with another Martin (Micah) from 8th Light (see http://forums.pragprog.com/forums/62/topics/2753 http://forums.pragprog.com/forums/62/topics/2753) - nice kid but I wouldn't want him writing code that I needed to rely on.

Nimi 13y ago
I find the described interaction problematic from an agile standpoint: "People and interactions over processes and tools" - and then, they agree to give a lecture on TDD? You're describing literally shoving a process down the throats of unwilling programmers. I'm not an agile expert, but it seems to me they should have refused such an arrangement, and plainly say: "Right now, you don't use an agile methodology. Us giving a lecture to your guys won't change that, it will simply be a waste of your money. You can rent from us an agile coach for minimum 6 months, and she will try to transition you to an agile methodology. This isn't a single decision you make and then 'bam, you're agile' - this affects hiring, you might even have to let go of programmers who won't play along. Don't pay us for a lecture that will simply anger your employees and achieve nothing." Regardless of the usual agile vs. waterfall debates, what they did sounds to me very far from the principles of being agile.
- robin2 13y ago
  In this case, I don't think the company can be blamed. As I recall, it hadn't asked for TDD training, it had asked for C++ training. So if anyone should be blamed it would be ObjectMentor for (a) hearing this as "introduction to object orientation", and (b) sending someone with rusty C++ skills.
  - Nimi 13y ago
    That's what I meant - even if your employer asked for TDD training, ObjectMentor should have objected on the grounds that it will achieve nothing.
    - robin2 13y ago
      Well, ObjectMentor got paid, someone at the company got to tick a box to say that developers had been given appropriate training, and we got a break from real work. Corporate training is an odd business, it has to be said.
  - unclebobmartin 13y ago
    At the time of that course, Micah was supporting a very large C++ application, and had been for some years. Were his skills rusty? I rather doubt it. In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?
- unclebobmartin 13y ago
  Nimi, the agile manifesto does not say "People and Interactions _instead_ of processes and tools". Indeed, the preamble to the manifesto is quite specific that we think processes and tools are good things. It's just that people and interactions should take precedence. In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.
  - Nimi 13y ago
    Thanks for replying. Could you elaborate on your stance? Obviously, being agile doesn't do away with processes and tools. But giving a lecture on TDD to unwilling programmers seems to guarantee the "people and interactions" part of the equation will be unsatisfactory. There's also the question (at least in my mind) of how this should be viewed in terms of customer collaboration - without attending that lecture, it seems to me that there's no collaboration here, robin2's employer pre-ordered something useless, and that's what they got. Where am I wrong? Obviously, teaching TDD in a collaborative and positive environment, and making sure the students are capable and willing to practice TDD would be very much "agile". Just in case that's not clear: I'm sincerely asking that with humility, there's not a doubt in my mind you have a much better grasp of what agile means - you defined it...
    - unclebobmartin 13y ago
      Nimi, to be clear, I did not define agile; I simply collaborated in the effort that defined it. In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.
unclebobmartin 13y ago
Dear Mr Newton. My memory of the Cambridge event a few years back is rather different from what you report. As I recall, the room was packed, the reception was enthusiastic, as was the applause; and the folks who talked with me later were excited and congratulatory. I don't know who you talked to, but -- perhaps it's best not to report on things that you didn't attend. As for Micah, my son, he runs a very successful software development company of 60 or so developers who specialize in extremely high quality software. He maintains very high standards for the developers who work for him. Every one of them practices TDD as well as many other practices that we've found to be beneficial. The result has been a steady stream of very satisfied customers and repeat business. Those customers would likely disagree with you about the reliability of his code; and the code of his employees. But then, I don't imagine your comment was based on any actual knowledge of his code. Perhaps it's best not to report on things you haven't seen.
- unclebobmartin 13y ago
  One last point. People like Donald Knuth and Brian Kernighan are heroes of mine. I would not sully their names by comparing them with the likes of me.
j_s 13y ago
Did this just blow straight past ad hominem to character assassination?!! This is the first time a post on HN has turned my stomach.
- unclebobmartin 13y ago
  I don't know Mr. Newton's beef. I found the virulence of his posts rather surprising since they were entirely off topic, and an attempt to make the topic about me, personally, rather than about what I wrote. Perhaps he will clarify.
  - robin2 13y ago
    OK, challenge accepted. I've only just noticed that this thread continued, and to be honest I doubt anyone will read this - but seeing as Mr Martin's responses aren't unreasonable I think they deserve an answer. I'll have to collect my thoughts, so more later...
  - deleted 13y ago
    [deleted]
  - robin2 13y ago
    [Part II] In another comment, Mr Martin suggests that something like a guild system might be an appropriate for software development, and I'm assuming that 8th Light's interest in apprenticeship reflects this line of thinking. This sort of talk is interesting, but runs the risk of sliding toward sub William Morris sentimentality, which would be a shame. As it happens, I know a small amount of economic history that might possibly be helpful. It's fairly obvious that the sort of industrial capitalism exemplified by, say, a 19th Century Lancashire cotton mill doesn't apply very well to software development. The capital costs involved in doing software development can, in extreme, be merely those of a laptop computer and an internet connection. This, I suspect, is what encourages the "rock star" model, which says that if you have some modicum of programming skill, the right idea, the right attitude and a bit of luck, then you too could become rich beyond the dreams of avarice. (See also http://quantumprogress.files.wordpress.com/2011/06/screen-shot-2011-06-09-at-12-49-03-am1.png http://quantumprogress.files.wordpress.com/2011/06/screen-sh...) Whilst I don't personally find this terribly attractive, is has a certain amount of logic to it. Similarly, if we are to look to an earlier model - master craftsmen and apprentices - then we should look at the forces at play, rather than just the image. One thing to understand about a traditional apprenticeship is that it was a serious commitment. As I recall, a typical period of indenture was seven years. Some of the reasons were economic; I'll give a couple of them. One reason not to rush towards the status of master craftsman was that obtaining that obtaining the tools of ones trade could itself take a very long time. As I recall, the most extreme example of this was with blacksmiths, who would typically have to wait to inherit the equipment they needed. Another reason for the length of indenture was to do with the fact that an apprentice wasn't an employee, and wasn't paid for his labour, but that the master had an obligation to house and feed him. So the cost of the apprentice's labour stayed the same, even though the value of the labour increased as the apprentice gained in experience. Hence it was, in this respect, in the masters' self-interest to have the indenture last a long time. Both the points I've just mentioned suggest a disanalogy more than anything else, and don't really do much to illuminate the contemporary situation. I've got a final point which I think is more telling. As I said, an apprentice wasn't an employee, and an indenture agreement was a mutual bond that carried obligations quite unlike those of a modern employer/employee relation. One of these was that a master couldn't let apprentices go when there wasn't sufficient revenue-generating work to keep them occupied. Even in lean years, a master was still responsible for the apprentices' keep, and they might be kept busy with, e.g., building up inventory in anticipation of future need. (This is, incidentally, one reason given for the decline of this system: masters preferred the flexibility of having hired hands that they only paid for when they needed them.) This contrasts very strongly with a modern corporation that has an obsession with every quarter's bottom line, and a hire-and-fire attitude towards its employees. Quite apart from the effect of this on morale, it potentially impacts skill acquisition: it is a dicey proposition for an employee to invest in skills that tie them to their current employers since they never know when they might have to look for something new. I don't how the tension between the requirements of craft and commercial reality can best be resolved. I don't know if it can be resolved at all. That's OK. Open questions are the interesting ones. Anyway, I've said my thing now. Over and out.

by robin2 13y ago

Nimi 13y ago

I find the described interaction problematic from an agile standpoint: "People and interactions over processes and tools" - and then, they agree to give a lecture on TDD? You're describing literally shoving a process down the throats of unwilling programmers. I'm not an agile expert, but it seems to me they should have refused such an arrangement, and plainly say: "Right now, you don't use an agile methodology. Us giving a lecture to your guys won't change that, it will simply be a waste of your money. You can rent from us an agile coach for minimum 6 months, and she will try to transition you to an agile methodology. This isn't a single decision you make and then 'bam, you're agile' - this affects hiring, you might even have to let go of programmers who won't play along. Don't pay us for a lecture that will simply anger your employees and achieve nothing." Regardless of the usual agile vs. waterfall debates, what they did sounds to me very far from the principles of being agile.

robin2 13y ago
In this case, I don't think the company can be blamed. As I recall, it hadn't asked for TDD training, it had asked for C++ training. So if anyone should be blamed it would be ObjectMentor for (a) hearing this as "introduction to object orientation", and (b) sending someone with rusty C++ skills.
- Nimi 13y ago
  That's what I meant - even if your employer asked for TDD training, ObjectMentor should have objected on the grounds that it will achieve nothing.
  - robin2 13y ago
    Well, ObjectMentor got paid, someone at the company got to tick a box to say that developers had been given appropriate training, and we got a break from real work. Corporate training is an odd business, it has to be said.
- unclebobmartin 13y ago
  At the time of that course, Micah was supporting a very large C++ application, and had been for some years. Were his skills rusty? I rather doubt it. In any case, --- what does this have to do with the article in the title line? It seems odd to be talking about something my son did nearly a decade ago in response to an article I wrote today?
unclebobmartin 13y ago
Nimi, the agile manifesto does not say "People and Interactions _instead_ of processes and tools". Indeed, the preamble to the manifesto is quite specific that we think processes and tools are good things. It's just that people and interactions should take precedence. In light of that, your contention that teaching TDD is "very far from the principles of being agile" is somewhat misguided. Quite to the contrary, to disregard processes and tools is what would be far from agile.
- Nimi 13y ago
  Thanks for replying. Could you elaborate on your stance? Obviously, being agile doesn't do away with processes and tools. But giving a lecture on TDD to unwilling programmers seems to guarantee the "people and interactions" part of the equation will be unsatisfactory. There's also the question (at least in my mind) of how this should be viewed in terms of customer collaboration - without attending that lecture, it seems to me that there's no collaboration here, robin2's employer pre-ordered something useless, and that's what they got. Where am I wrong? Obviously, teaching TDD in a collaborative and positive environment, and making sure the students are capable and willing to practice TDD would be very much "agile". Just in case that's not clear: I'm sincerely asking that with humility, there's not a doubt in my mind you have a much better grasp of what agile means - you defined it...
  - unclebobmartin 13y ago
    Nimi, to be clear, I did not define agile; I simply collaborated in the effort that defined it. In one post Robin2 described the course as OO, in another he described it as "C++". Those are two different courses so I'm not sure which it really was. However, back in those days we always did a brief lecture on TDD, as well as several other disciplines such as pairing, refactoring, etc. I was not at the class in question so I cannot comment on precisely what happened; but in general we tried to cover the bases of the various agile disciplines as part of any class we taught. Our customers knew this, and understood the implications. Object Mentor was, after all, the first and foremost of the Agile Transition companies. So all our courses had that flavor.

unclebobmartin 13y ago

Dear Mr Newton. My memory of the Cambridge event a few years back is rather different from what you report. As I recall, the room was packed, the reception was enthusiastic, as was the applause; and the folks who talked with me later were excited and congratulatory. I don't know who you talked to, but -- perhaps it's best not to report on things that you didn't attend. As for Micah, my son, he runs a very successful software development company of 60 or so developers who specialize in extremely high quality software. He maintains very high standards for the developers who work for him. Every one of them practices TDD as well as many other practices that we've found to be beneficial. The result has been a steady stream of very satisfied customers and repeat business. Those customers would likely disagree with you about the reliability of his code; and the code of his employees. But then, I don't imagine your comment was based on any actual knowledge of his code. Perhaps it's best not to report on things you haven't seen.

unclebobmartin 13y ago
One last point. People like Donald Knuth and Brian Kernighan are heroes of mine. I would not sully their names by comparing them with the likes of me.

j_s 13y ago

Did this just blow straight past ad hominem to character assassination?!! This is the first time a post on HN has turned my stomach.

unclebobmartin 13y ago
I don't know Mr. Newton's beef. I found the virulence of his posts rather surprising since they were entirely off topic, and an attempt to make the topic about me, personally, rather than about what I wrote. Perhaps he will clarify.
- robin2 13y ago
  OK, challenge accepted. I've only just noticed that this thread continued, and to be honest I doubt anyone will read this - but seeing as Mr Martin's responses aren't unreasonable I think they deserve an answer. I'll have to collect my thoughts, so more later...
- deleted 13y ago
  [deleted]
- robin2 13y ago
  [Part II] In another comment, Mr Martin suggests that something like a guild system might be an appropriate for software development, and I'm assuming that 8th Light's interest in apprenticeship reflects this line of thinking. This sort of talk is interesting, but runs the risk of sliding toward sub William Morris sentimentality, which would be a shame. As it happens, I know a small amount of economic history that might possibly be helpful. It's fairly obvious that the sort of industrial capitalism exemplified by, say, a 19th Century Lancashire cotton mill doesn't apply very well to software development. The capital costs involved in doing software development can, in extreme, be merely those of a laptop computer and an internet connection. This, I suspect, is what encourages the "rock star" model, which says that if you have some modicum of programming skill, the right idea, the right attitude and a bit of luck, then you too could become rich beyond the dreams of avarice. (See also http://quantumprogress.files.wordpress.com/2011/06/screen-shot-2011-06-09-at-12-49-03-am1.png http://quantumprogress.files.wordpress.com/2011/06/screen-sh...) Whilst I don't personally find this terribly attractive, is has a certain amount of logic to it. Similarly, if we are to look to an earlier model - master craftsmen and apprentices - then we should look at the forces at play, rather than just the image. One thing to understand about a traditional apprenticeship is that it was a serious commitment. As I recall, a typical period of indenture was seven years. Some of the reasons were economic; I'll give a couple of them. One reason not to rush towards the status of master craftsman was that obtaining that obtaining the tools of ones trade could itself take a very long time. As I recall, the most extreme example of this was with blacksmiths, who would typically have to wait to inherit the equipment they needed. Another reason for the length of indenture was to do with the fact that an apprentice wasn't an employee, and wasn't paid for his labour, but that the master had an obligation to house and feed him. So the cost of the apprentice's labour stayed the same, even though the value of the labour increased as the apprentice gained in experience. Hence it was, in this respect, in the masters' self-interest to have the indenture last a long time. Both the points I've just mentioned suggest a disanalogy more than anything else, and don't really do much to illuminate the contemporary situation. I've got a final point which I think is more telling. As I said, an apprentice wasn't an employee, and an indenture agreement was a mutual bond that carried obligations quite unlike those of a modern employer/employee relation. One of these was that a master couldn't let apprentices go when there wasn't sufficient revenue-generating work to keep them occupied. Even in lean years, a master was still responsible for the apprentices' keep, and they might be kept busy with, e.g., building up inventory in anticipation of future need. (This is, incidentally, one reason given for the decline of this system: masters preferred the flexibility of having hired hands that they only paid for when they needed them.) This contrasts very strongly with a modern corporation that has an obsession with every quarter's bottom line, and a hire-and-fire attitude towards its employees. Quite apart from the effect of this on morale, it potentially impacts skill acquisition: it is a dicey proposition for an employee to invest in skills that tie them to their current employers since they never know when they might have to look for something new. I don't how the tension between the requirements of craft and commercial reality can best be resolved. I don't know if it can be resolved at all. That's OK. Open questions are the interesting ones. Anyway, I've said my thing now. Over and out.