|
Would you read (YA) book on this topic? What would it take to get you to read such a book?
The reason I'm asking (and hoping for some somewhat serious answers) is that I got contacted by a publisher asking me if I'd be interested in writing such a book. Personally, my initial reaction is no - I don't think a lot of people actually think that XP works, and the only idea that I can come up with that might be interesting is to find development teams / companies that are actually successful (or not) with XP, and interview them, their managers, and maybe even their customers regarding how they got XP to work for them. That might even be fun to do!
Thoughts?
Marc
|
|
|
|
|
You could start by talking to these guys[^]
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
|
|
|
|
|
I'd imagine the only real use case for Pair programming (with respect to XP) is for cases where you're trying to perform a knowledge transfer or education of junior members of the team. Outside of that, I'd imagine it is really ineffective as a general rule of thumb for development.
modified 8-Nov-12 17:00pm.
|
|
|
|
|
Andrew Rissing wrote: the only real use case for XP is for cases where you're trying to perform a knowledge transfer or education of junior members of the team
Do you mean pair programming? That's only one aspect of XP.
|
|
|
|
|
True. I'll correct that...
|
|
|
|
|
I would think that most shops that are productive are streamlined to begin with and don't have the time to classify their development style. I think most successful places develop their own, then blog about it, then all the non-coding leeches that surround software want people to write books about it.
Honestly, it looks like another buzzword. Does every single type of process to write code need a name and subsequent book? I blame the leeches that surround the industry. Just watch http://www.bravotv.com/start-ups-silicon-valley[^] to see what I"m talking about.
|
|
|
|
|
wizardzz wrote: I think most successful places develop their own
Exactly my thinking.
Marc
|
|
|
|
|
wizardzz wrote: I think most successful places develop their own, ...
I think that there are very, very few places that are actually successful at process control. Regardless of methodology.
I also suspect that some people think they are successful with the following possible gotchas.
1. They have no metrics to back up the success.
2. They were evangelists before the process began and thus measure success by merely doing it without consideratin for the actual product delivery.
3. A single project within a very limited business domain/culture and they fail to see the advantages that the brought to the process in the first place.
|
|
|
|
|
jschell wrote: 2. They were evangelists before the process began and thus measure success by merely doing it without consideratin for the actual product delivery.
That's been my experience.
I've also found that some of these people can get software delivered faster, but it's also much (and I mean much) buggier and harder to maintain. (At one place, I swear the engineers from another team spent more time planning sprints, talking about them, recording their time, etc. than actually doing any engineering. They never delivered anything on time or even close to it, yet swore their methodology was the best. Ironically, the team I was on had no methodology at all except "get it done", yet delivered everything on time and in a remarkably stable way.)
|
|
|
|
|
I've implemented and measured pair programming (years ago) and it was astonishingly successful.
The main project was delivered on time, there was only one bug discovered in the first 6 months of running (a leap year error) and the code was beautiful, commented nicely and easy to maintain.
The cost of development was very slightly higher than estimated - but no more so than may have been without pair programming.
The team was small enough that there was no need for such thing as scrums - as the programming pairs just chatted.
This has just occurred to me - one of the reasons I think for the success was the sociability of the company - we were all friends as well as colleagues - so we were a genuine team.
At my current employer, it is very different - lots of argument about whose fault it was, and lots of disagreement about the best way to do something.
|
|
|
|
|
_Maxxx_ wrote: we were a genuine team.
That matters more than any methodology.
|
|
|
|
|
Truer words were rarely spoken
|
|
|
|
|
wizardzz wrote: Honestly, it looks like another buzzword.
A 10+ year old buzzword though. Intro to extreme programming was how I learned about agile development back in the 90s.
|
|
|
|
|
You have to admit, it's not named well.
|
|
|
|
|
wizardzz wrote: ...I think most successful places develop their own [style]...
Hey! Plenty of unsuccessful places (including my own) develop their own style, too!
|
|
|
|
|
Marc Clifton wrote: Thoughts?
What do you think you are going to get out of this?
You certainly won't get rich from the book. You might get rich because of noteriety from the book which leads to people considering you an expert. That presumes that you manage to write an half way decent book in a market that is not already saturated. And that you can then market yourself (not the book) via the opportunties that result from that. Or if you are already marketing yourself in an appropriate market then this could improve that.
You might also just enjoy seeing yourself as an author with no expectation of material gain. Nothing wrong with that as long as you expect nothing else.
Marc Clifton wrote: That might even be fun to do!
However interviewing is not writing. So if overall the entire process is not fun and/or you do not have the time to dedicate to this then it could be a problem.
|
|
|
|
|
I suspect Marc is one of those odd people who just like writing and I think is already considered an author, probably addicted to writing. I sometimes wonder if I should envy such people, I do enjoy their creations but actually doing the writing, I don't think so!
Oh and the proposed subject matter is just awful.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Marc Clifton wrote: What would it take to get you to read such a book?
You'd have to pay me. I suspect that defeats the purpose.
CPallini wrote: You cannot argue with agile people so just take the extreme approach and shoot him.
:Smile:
|
|
|
|
|
YA?
I would buy a copy for the office - so many people assume it won't work for them with little knowledge so reading techniques and examples might help.
I invented pair programming in the 80's so you can talk to me!
|
|
|
|
|
_Maxxx_ wrote: I invented pair programming in the 80's so you can talk to me!
That's odd: I thought I did that in the seventies.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
I could never work out how to do it well with punched cards and hollerith machines, had to wait until the vdu was prevalent to implement it properly.
Loads of people had done it previously with a guru/padwan relationship paradigm but I'm not aware of any true pair programming going on when I implemented it.
Of course, that doesn't mean it didn't exist.
|
|
|
|
|
In reality I think pair programming is awful. I did participate in it once about 20 years ago but it did not work. Out of all the mad ideas that have come about in IT (usually stolen form other disciplines anyway) this is the very worst.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Tried it once, didn't work, so it must be bad?
That's the trouble with a lot of things - you need to invest time and energy to Learn how to do things before casting judgement.
I have seen so many places try XP, do it badly with much staff resentment, then declare its crap and didn't work for them.
I have seen other places invest time and energy, training staff beforehand, bringing in experienced scrum masters etc. and they have implemented very successfully.
|
|
|
|
|
For 9 months! Not like I didn't give it a chance. I would quit before I'd do it again: it was a dumb idea then, it'll be a dumb idea now. The only way it might possibly work is if you have one dominant and one submissive personality which means it won't work anyway. We had to be separated at the end - we wound each other up terribly. He was a complete sunshine (as was I, I suppose). We should never have been in the same building, never mind sitting next to each other for extended periods.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Just because you are a misanthropic sunshine doesn't invalidate a technique - much in the same way as techniques of wall plastering are well known but i am crap at them - doesn't mean they're bad techniques!
it's not true about requiring one dominant and one submissive - it actually works very well with two similarly talented devs as long as they can work as a team.
the fact that when you tried it you butted heads shows a number of things, both about you and about the standards for the company; If there were that many things you disagreed on then something's up irrespective of pair programming.
If ou wen your separate ways and developed independently, then surely ou would each have developed source that the other disagreed with? So all you are doing is sweeping it under the carpet rather than bringing it out in the open and dealing with it.
mark merrens wrote: We should never have been in the same building, never mind sitting next to each other for extended periods.
yeah - sexual tension can be a bitch to deal with in the office 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
