8 ms·

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming

There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow. 4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out. 5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance. Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view. This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.

taneq 7y ago
I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.
- lioeters 7y ago
  Haha, me too, the voice in the back of my head pleaded, "Make it stop..!" Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach. However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.
  - ohwaitnvm 7y ago
    I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down. Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :) EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.
    - lioeters 7y ago
      Thank you for the perspective! Pivotal does sound like an exciting place to work. > [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP. For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together. > I also don't really mind interruptions Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive. I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.
      - ohwaitnvm 7y ago
        Yeah I'm not sure where verbal-only came from! We definitely do less upfront specification of say a whole project or months of work - we'd probably call that waterfall style and suggest that likely so many things contained therein will change or be outright wrong that it's better to have just a rough outline, and build definition as work gets closer to being actionable or executed. I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off. Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)
irrational 7y ago
This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.
- coblers 7y ago
  I'm relatively outgoing and it still sounds horribly draining
- afarrell 7y ago
  I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.
  - atoav 7y ago
    Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I’d probably leave the room and think alone till I have something worthy of discussion
    - afarrell 7y ago
      Me: “What was the problem again? I forgot.” 5x times until my pairing partner just does it himself while I try to stay focused and follow along.
  - afarrell 7y ago
    To clarify, I'd be fine with pairing 8 hours a day, but I'd want: - Some sort of sound barrier so that I couldn't parse the background conversations. - To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.
    - havocheavy 7y ago
      Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations? Did it propel your conversation at all, or maybe give you something to talk about? When people talk about the buzz of activity in a busy place, it's really closer to a situation like this. Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience. On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.
pflenker 7y ago
As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?
- rramadass 7y ago
  The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight. You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.
- mikekchar 7y ago
  I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful. The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience. Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!" Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks. One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now. For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try. To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".
onion2k 7y ago
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are. It's on the engineering blog of a company trying to hire a ton of developers at the moment and it reads like the most toxic work environment imaginable to anyone who doesn't have that context, so perhaps the author and the team who approve blog posts should have made that MUCH clearer.
klohto 7y ago
I love this, makes me want to join team that practices this. What is your book name? I would like to buy it.
- jdlshore 7y ago
  The Art of Agile Development. It's published by O'Reilly and quite a bit of it is excerpted on my blog at https://www.jamesshore.com/Agile-Book/ https://www.jamesshore.com/Agile-Book/ .
  - klohto 7y ago
    No chance of hardcover?
    - jdlshore 7y ago
      The hardcopy print edition is available from Amazon or directly from O'Reilly, if that's what you mean. There's a link to the Amazon listing at the URL I gave you. As far as I know, there's only one type of printing, and that's a lay-flat softcover.
ahartmetz 7y ago
4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself.
- _betty_ 7y ago
  I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature. This practice is just saving time writing down behaviour that won't be implemented.
  - afarrell 7y ago
    But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction? What do you do when people forget things?
    - peteradio 7y ago
      You artfully interrupt them and always keep watch on what other people are doing!
    - _betty_ 7y ago
      4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out. There's still something written down, just not massive amounts. Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development. Otherwise I just communicate a lot. Things get differently from what I invisioned, sometimes they're worse sometimes they're better.
- lazerwalker 7y ago
  An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large. Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.
systemtest 7y ago
When I read "pairing stations" I gagged.
tuxxy 7y ago
I've been reading a lot on focused work and this sounds like the exact opposite of what's supposed to happen. I can't recommend Cal Newport's book "Deep Work: Rules for focused success in a distracted world" enough. He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests. He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.
- kd5bjo 7y ago
  I can second the recommendation for Deep Work, but it’s not the end of the story. Richard Hamming points out in You and Your Research that the researchers who were open to distraction tended to do a better job figuring out what to work on. In Programming as Theory Building, Peter Naur argues that the primary focus on a programming team should be developing a shared understanding of the problem space in which the program will operate. While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.
twic 7y ago
> This material is not meant for people who aren't on an XP team. It's good advice for product managers who are. No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting. If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about. It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.
Graham24 7y ago
I'd rather work on the bins.
JustSomeNobody 7y ago
> 1) All production programming is done in pairs, all the time. I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.
lonelappde 7y ago
When do they stop and think? When do they write documentation? They solved the problem of breaking flow by banning flow in the first place?
rev12 7y ago
> 4) Requirements are conveyed verbally, not through written documents. I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along. I admit to knowing very little about XP but this sounds like my own personal hell.
DonnyV 7y ago
This sounds like hell.

taneq 7y ago

I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.

lioeters 7y ago
Haha, me too, the voice in the back of my head pleaded, "Make it stop..!" Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach. However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.
- ohwaitnvm 7y ago
  I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down. Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :) EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.
  - lioeters 7y ago
    Thank you for the perspective! Pivotal does sound like an exciting place to work. > [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP. For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together. > I also don't really mind interruptions Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive. I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.
    - ohwaitnvm 7y ago
      Yeah I'm not sure where verbal-only came from! We definitely do less upfront specification of say a whole project or months of work - we'd probably call that waterfall style and suggest that likely so many things contained therein will change or be outright wrong that it's better to have just a rough outline, and build definition as work gets closer to being actionable or executed. I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off. Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)

irrational 7y ago

This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.

coblers 7y ago
I'm relatively outgoing and it still sounds horribly draining
afarrell 7y ago
I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.
- atoav 7y ago
  Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I’d probably leave the room and think alone till I have something worthy of discussion
  - afarrell 7y ago
    Me: “What was the problem again? I forgot.” 5x times until my pairing partner just does it himself while I try to stay focused and follow along.
- afarrell 7y ago
  To clarify, I'd be fine with pairing 8 hours a day, but I'd want: - Some sort of sound barrier so that I couldn't parse the background conversations. - To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.
  - havocheavy 7y ago
    Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations? Did it propel your conversation at all, or maybe give you something to talk about? When people talk about the buzz of activity in a busy place, it's really closer to a situation like this. Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience. On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.

pflenker 7y ago

As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?

rramadass 7y ago
The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight. You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.
mikekchar 7y ago
I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful. The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience. Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!" Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks. One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now. For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try. To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".

onion2k 7y ago

This material is not meant for people who aren't on an XP team. It's good advice for product managers who are. It's on the engineering blog of a company trying to hire a ton of developers at the moment and it reads like the most toxic work environment imaginable to anyone who doesn't have that context, so perhaps the author and the team who approve blog posts should have made that MUCH clearer.

klohto 7y ago

I love this, makes me want to join team that practices this. What is your book name? I would like to buy it.

jdlshore 7y ago
The Art of Agile Development. It's published by O'Reilly and quite a bit of it is excerpted on my blog at https://www.jamesshore.com/Agile-Book/ https://www.jamesshore.com/Agile-Book/ .
- klohto 7y ago
  No chance of hardcover?
  - jdlshore 7y ago
    The hardcopy print edition is available from Amazon or directly from O'Reilly, if that's what you mean. There's a link to the Amazon listing at the URL I gave you. As far as I know, there's only one type of printing, and that's a lay-flat softcover.

ahartmetz 7y ago

4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself.

_betty_ 7y ago
I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature. This practice is just saving time writing down behaviour that won't be implemented.
- afarrell 7y ago
  But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction? What do you do when people forget things?
  - peteradio 7y ago
    You artfully interrupt them and always keep watch on what other people are doing!
  - _betty_ 7y ago
    4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out. There's still something written down, just not massive amounts. Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development. Otherwise I just communicate a lot. Things get differently from what I invisioned, sometimes they're worse sometimes they're better.
lazerwalker 7y ago
An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large. Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.

systemtest 7y ago

When I read "pairing stations" I gagged.

tuxxy 7y ago

I've been reading a lot on focused work and this sounds like the exact opposite of what's supposed to happen. I can't recommend Cal Newport's book "Deep Work: Rules for focused success in a distracted world" enough. He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests. He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.

kd5bjo 7y ago
I can second the recommendation for Deep Work, but it’s not the end of the story. Richard Hamming points out in You and Your Research that the researchers who were open to distraction tended to do a better job figuring out what to work on. In Programming as Theory Building, Peter Naur argues that the primary focus on a programming team should be developing a shared understanding of the problem space in which the program will operate. While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.

twic 7y ago

> This material is not meant for people who aren't on an XP team. It's good advice for product managers who are. No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting. If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about. It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.

Graham24 7y ago

I'd rather work on the bins.

JustSomeNobody 7y ago

> 1) All production programming is done in pairs, all the time. I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.

lonelappde 7y ago

When do they stop and think? When do they write documentation? They solved the problem of breaking flow by banning flow in the first place?

rev12 7y ago

> 4) Requirements are conveyed verbally, not through written documents. I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along. I admit to knowing very little about XP but this sounds like my own personal hell.

DonnyV 7y ago

This sounds like hell.