Hacker News Reader

Comment by ww520 | Hacker News Reader

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.

View on HN

> 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.

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.

These can all be real problems but they say nothing about pair programming or agile and everything about the toxic culture at some places

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.

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.

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.

(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.

Lean, applied to software, would mean that the software team can see opportunities to improve their process and/or tools, and would have the power to do so.

I've actually been on a team that did this. "For the next two-week iteration, we're going to change the process in this way, and we'll see how that works."

Process doesn't have to be a static thing handed down from on high. Hack it. Make it work for you. (One of the agile approaches to software is "pay attention to pain". That is, when it's hard to change the software in some way, that's telling you that it should be refactored so that it quits being hard to change it in that way. Well, the same thing works for process. If the process is painful, pay attention. It's telling you that you need to change the process.)

> Lean, applied to software, would mean that the software team can see opportunities to improve their process and/or tools, and would have the power to do so.

Yes, that's exactly what Lean in software means (and you'll note that it has a very close relation to Agile principles -- Lean is pretty much Agile with more focus on measurable output and several decades more of development behind it -- both for the good and the bad [there's a lot of depth in the literature of practices and how and when they work to draw from for your circumstances, but there's also breadth and depth in the buzzword snake-oil].)

Agile & Lean have quite a few things in common such delivering lots of little chunks of value to customer as fast possible. Not doing things in large batches etc. Asking the people doing the work to implement improvements, since they know the work etc

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.

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.

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.

> 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.

> 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.

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.

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.

Reply on news.ycombinator.com