4 ms·

I think I've realized over the years that this kind of development process lends itself to certain kinds of software. In particular XP is effective for web serv

by ascotan 12y ago

I think I've realized over the years that this kind of development process lends itself to certain kinds of software. In particular XP is effective for web server products. Not all software can or should be deployed rapidly like this. It's been my experience that end users don't really want constant churn in their software unless it's transparent to them. It's also hard to justify having 11 SEs sitting around a monitor programming. Their combined rate is probably something like 2million a year with overhead. with that kind of burn rate you'd better have some serious productivity from the 1 guy on the keyboard.

lighthawk 12y ago
> In particular XP is effective for web server products. I was on a team that used it effectively to develop a Java back-end framework, which was not web services nor hosted by a web server. While I agree not everything fits into XP, you can't classify it like that. Mob programming is not classical XP, but it is in the same spirit of pair programming. It can burn a lot of money per feature developed and LOC written, you need to also consider the mentoring/learning aspect of it. Same goes with pair programming. It isn't only about code quality. It is about mentoring/sharing/learning. Don't get me wrong- if you've never pair programmed for a long time before, you don't know really understand the meaning of the word "annoyance", and if you don't have the right setup, one person may zone-out and not really be helping. Doing it right is an art. If you learn a way to do it correctly, it will really help: your developers will be more productive because they learn from each other, there will be less churn resulting from any formal code reviews that might be required if you need formal sign-off (if required at all) and there will be fewer bugs. Fewer bugs mean: less work for helpdesk/customer service, fewer adversely affected users within the company, fewer periods when you aren't taking orders/etc. which cause lost revenue and customer frustration which can lead to them telling others about their bad experience and losing additional opportunities, etc. But, odds are unless you try things out, tune them, try again, no matter what methodology you choose, you're going to get something wrong. It doesn't matter what you are developing. Hone it.
falcolas 12y ago
I agree with this. Of late I've actually become a bit annoyed with our Slack install, because it keeps changing. What can and can't I do with our chat tool? Who knows! It'll be different tomorrow. I used to lambast my colleagues for having chosen to use IRC over more modern tools like Jabber or Hangouts. I realize now how foolish I was. Some software just don't need to change continuously.
- 101914 12y ago
  "Some software just don't need to change continuously."
  - 101914 12y ago
    Ha. Initially this quote got upvoted. Then it was downvoted. Is this a controversial subject?
iopq 12y ago
What? That's like saying that programming is easy because it's just typing. It's not about how fast the guy with the monitor writes things! It's about making the right choice when you're designing a system. When I do programming by myself I go through many designs and refactorings. If someone already mentioned "hey, don't allocate on the hot path" and "make a closure here instead of copy pasting" and so forth without me having to be concerned about code quality and performance I'd get things done faster. I usually implement a very naive first version. If after typing this up I already have 3-4 people fixing it, then my pull request can have good performance, style, etc. from the get-go and get merged pretty fast instead of constant "can you fix this, then I'll merge it?"
- lojack 12y ago
  I think we can all agree that the keyboard isn't the limiting factor here. Individual programmers at their own keyboards can all focus on separate problems. Two (or more) programmers with a single keyboard can only focus on a single problem at a time, but they get the experience and perspective of multiple developers. It's really just a matter of breadth of focus vs depth of focus. At a certain point adding more developers won't help and it will end up wasting resources. This may be as soon as you add a second developer, or maybe after you add 6 developers.

by ascotan 12y ago

lighthawk 12y ago

> In particular XP is effective for web server products. I was on a team that used it effectively to develop a Java back-end framework, which was not web services nor hosted by a web server. While I agree not everything fits into XP, you can't classify it like that. Mob programming is not classical XP, but it is in the same spirit of pair programming. It can burn a lot of money per feature developed and LOC written, you need to also consider the mentoring/learning aspect of it. Same goes with pair programming. It isn't only about code quality. It is about mentoring/sharing/learning. Don't get me wrong- if you've never pair programmed for a long time before, you don't know really understand the meaning of the word "annoyance", and if you don't have the right setup, one person may zone-out and not really be helping. Doing it right is an art. If you learn a way to do it correctly, it will really help: your developers will be more productive because they learn from each other, there will be less churn resulting from any formal code reviews that might be required if you need formal sign-off (if required at all) and there will be fewer bugs. Fewer bugs mean: less work for helpdesk/customer service, fewer adversely affected users within the company, fewer periods when you aren't taking orders/etc. which cause lost revenue and customer frustration which can lead to them telling others about their bad experience and losing additional opportunities, etc. But, odds are unless you try things out, tune them, try again, no matter what methodology you choose, you're going to get something wrong. It doesn't matter what you are developing. Hone it.

falcolas 12y ago

I agree with this. Of late I've actually become a bit annoyed with our Slack install, because it keeps changing. What can and can't I do with our chat tool? Who knows! It'll be different tomorrow. I used to lambast my colleagues for having chosen to use IRC over more modern tools like Jabber or Hangouts. I realize now how foolish I was. Some software just don't need to change continuously.

101914 12y ago
"Some software just don't need to change continuously."
- 101914 12y ago
  Ha. Initially this quote got upvoted. Then it was downvoted. Is this a controversial subject?

iopq 12y ago

What? That's like saying that programming is easy because it's just typing. It's not about how fast the guy with the monitor writes things! It's about making the right choice when you're designing a system. When I do programming by myself I go through many designs and refactorings. If someone already mentioned "hey, don't allocate on the hot path" and "make a closure here instead of copy pasting" and so forth without me having to be concerned about code quality and performance I'd get things done faster. I usually implement a very naive first version. If after typing this up I already have 3-4 people fixing it, then my pull request can have good performance, style, etc. from the get-go and get merged pretty fast instead of constant "can you fix this, then I'll merge it?"

lojack 12y ago
I think we can all agree that the keyboard isn't the limiting factor here. Individual programmers at their own keyboards can all focus on separate problems. Two (or more) programmers with a single keyboard can only focus on a single problem at a time, but they get the experience and perspective of multiple developers. It's really just a matter of breadth of focus vs depth of focus. At a certain point adding more developers won't help and it will end up wasting resources. This may be as soon as you add a second developer, or maybe after you add 6 developers.