5 ms·

The Agile processes are ways for managers to enforce a manufacturing-like process to software development to micro manage development activities to squeeze ever

by ww520 13y ago

The Agile processes are ways for managers to enforce a manufacturing-like process to software development to micro manage development activities to squeeze every little bit of productivity out of developers in the expense of creativity. They work well for managing junior developers or for body shop. Senior developers hate them. The daily meetings usually turn into daily status meetings, no matter how much the Agile advocates claim otherwise. The rough estimate become a hard deadline, with daily remainder of why it's slipping. Pair programming - free training for junior developers, a waste of time for senior developers.

acdha 13y ago
> Pair programming - free training for junior developers, a waste of time for senior developers. The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.
- logfromblammo 13y ago
  It wouldn't be a waste of time if there were not an endemic bias against both having older developers and paying them more for their experience. As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team. If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that. So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming. If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.
  - acdha 13y ago
    These can all be real problems but they say nothing about pair programming or agile and everything about the toxic culture at some places
    - logfromblammo 13y ago
      You can take a process that grows out of a healthy culture and transplant it into a toxic one. Agile practices and pair programming cannot be divorced from the team culture. To do otherwise is cargo cult ritual management. There is very little inherent to pair programming in itself that can be considered good or bad in isolation from the people using it. Good teams follow good practices. This is not because the practices are good, but because the team finds them to be temporarily useful to meet their specific needs. If your manager went to a conference, learned about agile stuff, and returned to institute pair programming, you will likely find that to be of dubious value. If your team decides internally that the new hire should do pair programming with each of the existing team members until the greenness fades, that will probably have a better outcome.
- ww520 13y ago
  Pair programming is not training. It is not the main function of pair programming. The fact training becomes the most important reason trumpeted for pair programming speaks fully how ill conceited the concept is. I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.
  - city41 13y ago
    Pair programming is a tool just like everything else. It should be used when it's effective and not used when it's not. It can be effective at times. I completely agree that 8 hours a day, 5 days a week pair programming is highly ineffective.
- deleted 13y ago
  [deleted]
dragonwriter 13y ago
(1) There are no such thing as "Agile processes", and anyone that tells you there is is lying to sell you a process. (2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.
- ferentchak 13y ago
  There are agile practices though. Some of them are so simple we don't even think of them as being a practice. Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.
  - dragonwriter 13y ago
    I think the important thing to keep in mind is that while Agile principles may sometimes be commonly well served by certain sets of practices or processes, the practices/processes themselves are usually not Agile (except for the high-level process of evaluating and selecting processes -- Agile is about choosing the process that works for the actual set of people you have, not about choosing process based on considerations outside of the work groups ability to produce quality software.) The ossification of Agile into a set of cargo cult practices divorced from the particular teams and their needs flips Agile into exactly what it was a reaction against.
    - ferentchak 13y ago
      I agree 100%. In my experience the main thing to keep in mind to improving any system is to: 1. See what state you are in 2. Figure out what new state you would like to be in 3. Guess at something that will help you move into that state and then follow that guess. 4. See if that move helped you get closer to that state 5. goto 1 People label those steps with lots of names depending on what industry they work in but in the end that is the easiest way to get better.
allsystemsgo 13y ago
> Pair programming - free training for junior developers, a waste of time for senior developers. I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.
- Nursie 13y ago
  Who wants to build a team? Some of us are just there to get the job done and get out... I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.
- mkal_tsr 13y ago
  > Also, senior developers who can't pair program, aren't senior developers. Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move. You know when pair programming is endorsed by the senior developers? Root-causing bugs.
- ww520 13y ago
  I disagree. You don't need pair programming to build a team. Overwhelming percentage of successful teams exist without pair programming. One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming. Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.

by ww520 13y ago

acdha 13y ago

> Pair programming - free training for junior developers, a waste of time for senior developers. The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.

logfromblammo 13y ago
It wouldn't be a waste of time if there were not an endemic bias against both having older developers and paying them more for their experience. As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team. If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that. So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming. If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.
- acdha 13y ago
  These can all be real problems but they say nothing about pair programming or agile and everything about the toxic culture at some places
  - logfromblammo 13y ago
    You can take a process that grows out of a healthy culture and transplant it into a toxic one. Agile practices and pair programming cannot be divorced from the team culture. To do otherwise is cargo cult ritual management. There is very little inherent to pair programming in itself that can be considered good or bad in isolation from the people using it. Good teams follow good practices. This is not because the practices are good, but because the team finds them to be temporarily useful to meet their specific needs. If your manager went to a conference, learned about agile stuff, and returned to institute pair programming, you will likely find that to be of dubious value. If your team decides internally that the new hire should do pair programming with each of the existing team members until the greenness fades, that will probably have a better outcome.
ww520 13y ago
Pair programming is not training. It is not the main function of pair programming. The fact training becomes the most important reason trumpeted for pair programming speaks fully how ill conceited the concept is. I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.
- city41 13y ago
  Pair programming is a tool just like everything else. It should be used when it's effective and not used when it's not. It can be effective at times. I completely agree that 8 hours a day, 5 days a week pair programming is highly ineffective.
deleted 13y ago
[deleted]

dragonwriter 13y ago

(1) There are no such thing as "Agile processes", and anyone that tells you there is is lying to sell you a process. (2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.

ferentchak 13y ago
There are agile practices though. Some of them are so simple we don't even think of them as being a practice. Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.
- dragonwriter 13y ago
  I think the important thing to keep in mind is that while Agile principles may sometimes be commonly well served by certain sets of practices or processes, the practices/processes themselves are usually not Agile (except for the high-level process of evaluating and selecting processes -- Agile is about choosing the process that works for the actual set of people you have, not about choosing process based on considerations outside of the work groups ability to produce quality software.) The ossification of Agile into a set of cargo cult practices divorced from the particular teams and their needs flips Agile into exactly what it was a reaction against.
  - ferentchak 13y ago
    I agree 100%. In my experience the main thing to keep in mind to improving any system is to: 1. See what state you are in 2. Figure out what new state you would like to be in 3. Guess at something that will help you move into that state and then follow that guess. 4. See if that move helped you get closer to that state 5. goto 1 People label those steps with lots of names depending on what industry they work in but in the end that is the easiest way to get better.

allsystemsgo 13y ago

> Pair programming - free training for junior developers, a waste of time for senior developers. I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.

Nursie 13y ago
Who wants to build a team? Some of us are just there to get the job done and get out... I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.
mkal_tsr 13y ago
> Also, senior developers who can't pair program, aren't senior developers. Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move. You know when pair programming is endorsed by the senior developers? Root-causing bugs.
ww520 13y ago
I disagree. You don't need pair programming to build a team. Overwhelming percentage of successful teams exist without pair programming. One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming. Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.