18

I recently became the lead on a new team. My previous team was more pure software development. We pair-programmed ~80% of the time utilizing TDD.

My new team is in charge of supporting, maintaining, and releasing features for a suite of microservices on Kubernetes. I would estimate we spend < 5% of our time doing TDD/programming but management wants us to pair on almost everything.

Here's my understanding of the purpose of pair programming:

  • it decreases the number of bugs in software
  • it is most effective when done while following TDD practices

Management has said the following when I brought this up:

  • pairing for our team will help spread the knowledge of what we are learning and doing in the project space

Since I'm new both to being a team lead and working in an environment that is not focused on software development I'd like to get feedback on this. Is pairing an effective strategy for non-programming related tasks? Have there been studies around pairing on admin/configuration tasks?

|improve this question
  • 17
    What do you have to lose by just giving it a try? – Helena Oct 28 at 21:30
  • 8
    I'm not asking the question to find reasons not to do it, I'm asking to get feedback from people who have experience with this. Please read my last two questions in my post. – Bilbo Baggins Oct 28 at 21:40
  • this is pretty broad question right now. @Helena point makes me think: what issue do you have with following order from management? – aaaaa says reinstate Monica Oct 28 at 22:13
  • As I already stated, I don't have an issue pairing but it goes against my knowledge of what the purpose of pairing is so I asked for feedback. – Bilbo Baggins Oct 28 at 22:47
  • 2
    My experience is that ops/devops is where shared knowledge and risks caught by a second person is even more important than in programming; I believe that mandated "four eyes principle" in sensitive configuration management (at least in some industries) is an approach that predates the rise of the concept of pair programming. – Peteris Oct 29 at 10:19
50

I have some experience with this from the other side. We did not have much pairing when rebuilding our Kubernetes infrastructure recently. The person who built most of the new infrastructure is now on parental leave every other week for the rest of the year. Every time they are gone we have to scramble to solve problems. This means we are losing development time and also carry various risks related to not completely understanding the hosting environment.

Your upper management are trying to increase the bus factor by asking you to let multiple people be part of every component. There are definitely other ways to achieve this goal so if you and your team think you can solve knowledge sharing in a more efficient way, go ahead and talk to your management. Just make sure your solution is not going to end up an incomplete half-hearted attempt at documentation.

I am also not sure why you consider configuration to be "not development". You are developing a hosting environment. In our team, we do not have many tests for the Kubernetes system. But the config system is put under source control and we use code review on everything, just like we would in our development codebases. This is both for quality assurance and for knowledge sharing.

|improve this answer
  • The "bus factor" is a great term for what's happening and will be useful when discussing this with the team. Regarding semantics around "development" - I only brought up development in reference to "software development" which I view as programming, where TDD comes into play, hence the question. – Bilbo Baggins Oct 28 at 22:52
  • 1
    Pair programming and working on intersecting parts of a project are not the same thing. In my opinion the initial example does therefore not hold, because the problem could have been resolved without pair programming. – Mär Oct 29 at 10:21
  • Obviously it is only programming if it is Turing complete. On the other hand I wouldn't be that surprised if someone told me that windows ini files are Turing-complete. (I mean, I doubt they are, but there could be a "include other ini file" syntax in them; add that, and a condition, and it could go over the edge) – Yakk Oct 29 at 14:23
  • 1
    @Mär The problems pairing solves can also be resolved in some other way.That is not a sufficient reason for it to be unnecessary or inappropriate here. Those other ways may have more overhead, take more time to bring additional people up to speed, may be hard to maintain, etc. For the most part, first hand experience is always better than reading documentation written by someone else. – iheanyi Oct 29 at 20:05
  • 1
    It is a sufficient reason, because this thread specifically asks about pair programming, not about knowledge transfer. – Mär Oct 30 at 7:23
20

I think you are focusing to much on the term in a programming sense. By working with another, you can teach and learn from each other.

For example, early in my IT career, I was a sales engineer for a software product. I was "paired" with a salesperson. We would travel to potential customers to sell them the product. He focused on selling and I focused on how it could be integrated and implemented. I learned a lot from him on how to convince a customer to buy, while he learned the technical side from me. We both benefited from working together. This allowed us to eventually work alone, yet be as effective as the pair. He could explain to potential customers the technical aspects, without the need for me to be there. While supporting the product, I could effectively sell and recommend additional products and services. It definitely was effective and helped the company. I was able to use the sales knowledge throughout my career.

There is no reason that pairing cant benefit in many different disciplines, if utilized properly.

|improve this answer
  • 4
    Pairing can also be used so that more than one person can do tasks, so there isn't a single point of failure if a person takes a vacation or new job. – thursdaysgeek Oct 28 at 21:53
  • @thursdaysgeek that is true, as well. Although good documentation should allow anyone to do any task, spreading the knowledge definitely helps. – Keltari Oct 28 at 21:56
  • 1
    Yeah, it's not like pairing is some ultra-modern methodology. People have been pairing up to do work for millenia. Whenever you need to do a knowledge transfer or whenever you're designing something, pairing is a great strategy. Just make sure the results are worth having two people on a task rather than just one - a cost-benefit calculation like any other. Communication is hard. Pairing makes communication so natural you barely notice you're communicating; especially given how prone people are to overestimating how much they understand each other when merely talking :) – Luaan Oct 29 at 7:37
  • Not everybody works well in those conditions. Though reducing bus factor is good. – Lightness Races with Monica Oct 29 at 16:20
8

Is pairing an effective strategy for non-programming related tasks?

That's not your call. It's whatever management decides it is. They're the ones with theoretically the knowledge and specific experience to make the call.

And yes, it is a reasonable way of spreading knowledge and pooling resources.

|improve this answer
  • 1
    I disagree with blindly following management's decisions. The company I work for values personal opinionated input so I'm defining my input by asking this question. – Bilbo Baggins Oct 29 at 17:03
  • 1
    Management pays many of us to give feedback or suggestions when our professional knowledge and experience shows there's a better way to solve a particular problem. – iheanyi Oct 29 at 20:08
  • 1
    @Kilisi By virtue of coding and working with a team of developers, OP has experience with working on a team. And specifically, OP has direct experience working with his team in his work environment. This experience management may not have. So, he's in a position to provide feedback along the lines of - this process you're asking us to follow may not be the best for our team to accomplish the stated goal. I get these "ideas" from my many years of life and (lesser years) of working in various organizations and teams. – iheanyi Oct 30 at 0:52
  • 1
    I got side tracked - another issue with your answer is that They're the ones with theoretically the knowledge and specific experience to make the call is not always true. However, management does have to make a decision. Sometimes, that will involve directly asking the people carrying out work for input in reaching goals. Depending on the job, it is not unusual for an employee to provide feedback. Also, as I've alluded to, management in many cases is disconnected from day to day work and may necessarily not have insight into things which the employee would have. – iheanyi Oct 30 at 0:55
  • 1
    @Kilisi - your comment implied two things - that the OP doesn't have the experience to challenge management's decision and that you cannot understand why I (and I assume Bilbo Baggins) would even think about disagreeing with management in the first place. My response addressed those two issues by pointing out that coding provides more experience than simply coding and my personal experience that leads me to disagree with your answer. I've already downvoted. I was just following up with why so if you were so motivated, you could edit the answer which then allows me to reverse the downvote. – iheanyi Oct 30 at 0:59
1

Have there been studies around pairing on admin/configuration tasks?

Not studies, but for one thing, this would help mitigate the problem of an admin hoarding the passwords to critical systems, or being lazy with security.

|improve this answer
1

First, be assured that you are not forwarding to the wrong direction.

Is pairing an effective strategy for non-programming related tasks?

This is called delegation & cross-functioning. You & team had done great efforts to make great software but only team knows it best. Other business functions like support, marketing, accounting also needs to know this software (product) better in order to get their roles performed best. Therefore you guys will be spreading your knowledge with them. And also be listening to them because they are non-programmers and might be the best teachers to give future improvements or ideas to your software.

Have there been studies around pairing on admin/configuration tasks?

Most organizations have been benefited by use of such pairing (also called delegation or cross-functioning). If your management is ready to take risk of delegation/cross-functioning outcomes then you shall not worry and participate in all activities positively.

Also, take this as learning opportunity for yourself too becasue programmers also need to keep improving self.

|improve this answer
1

Deliver the outcome management want. Picking the method is your job.

You're the team lead, you're in charge of coordinating your team to produce the outcome that management want.

In this case, they want to be sure knowledge sharing is happening systematically between staff.

It's your job to deliver that outcome in the best way. They might have suggestions on how to achieve it, that's fine. But you're the expert in the work your team does and the people in it. You're closest to the action, you have the context and the specialised knowledge to make the best call here.

If you're confident there's a better tool at your disposal than pairing to get knowledge sharing happening in your team, use that instead. Perhaps convincing management and getting approval first if that's necessary.

If the outcome is what they want (better knowledge sharing in this team), you're doing your job well as a team lead. More than that, you're actively not doing your job well if you know there is a better way to achieve this outcome and you don't push for it, unquestioningly following instructions instead. The more senior you get, the more it's important to question fundamentals and conventions -- the why and how more than the what -- and respectfully push back on them if you see better ways of doing things.

|improve this answer
1

Can you cause damage as an admin?

Through customizing one can cause real harm to clients/your company, its nature depending on the system.
Imagine the admin rolling out his account info to your VPoS terminal. Will the service still work perfectly? Yes. Will the company get its money? No.
Even an honest mistake can invalidate a full testing cycle and trash the testing system, causing 4-6 digit damage, again depending on the system.
Four eyes principle (i.e. the same person shall not set up customizing and transport it through the pipeline) is therefore ensured by quality assurance/auditors, admin pairing is an additional security measure.
In addition to the above there's employee turnover, health issues, vacation synchronization etc. that require at least two persons to feel comfortable with any single task. If your employer was also taking this into consideration you might have a place where there are enough resources to do the tasks assigned.
In any case every sign has a story: ask your peers, you may learn a lesson.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.