1

Many resources quote that average programmer writes an average 10 lines of code per day. https://www.google.com/search?client=opera&q=how+many+lines+of+code+do+programmers+write+a+day&sourceid=opera&ie=UTF-8&oe=UTF-8

As per my understanding, this might be due to different reasons:

  1. slow dev environment - there is a need to rebuild huge code base
  2. unclear requirements - developer spend time thinking of the best way to implement requirement he does not fully understand
  3. resolving merge conflicts
  4. thinking of the best way to build a class, method, stored procedure
  5. reviewing code of other developers
  6. waiting for feature to be tested by qa
  7. updating statuses of the tasks in bug tracking system
  8. investigating the cause of a bug

I do not know how to solve problem 1) Problems 2-8 might be solved in a following way: Developers, Business analyst, Product owner, Software Architect, Dev Ops write code together. Together, I mean, with one monitor and one keyboard.

Then if:

  1. problems with dev environment - devops immediately helps to fix it
  2. unclear requirement - product owner tells how to resolve uncertainty
  3. there is no merge conflicts, cause there is no need for merges. If code base is huge and require multiple teams to work on development in parallel, you will not avoid this problem completely. But merges will be far less frequent.
  4. thinking of the best way to build a class, method, stored procedure - software architect will help immediately to resolve the problem
  5. there is no need to review the code, because it is already reviewed by other devs, BA, Dev Ops and Architect)
  6. there is no need for software testers at this stage. Such team can think of all possible cases in 10-30min and check it right after feature is ready. Non functional testing can be performed later.

Cons

  1. Good approach only for development of a new products. Not so good for support of a huge code base.
  2. Budget. Such team will be more productive compared to other teams. So if team 2X more productive, it should be payed 2X per month. Not all businesses can afford that. This can be solved by reducing working day to 4 hours. Or giving programmers additional holidays.
sergey chubuk
  • 19
  • 1
  • Welcome to PMSE! Interesting ideas. What is stopping you from trying these out? – Ashok Ramachandran Jun 05 '21 at 08:56
  • 2
    Trying to reconcile the question title with the question content left me a bit confused. Are you saying that there are advantages to doing pair/mob programming, and ask why isn't everyone doing it? Is that your question? – Bogdan Jun 05 '21 at 12:14
  • 1
    This question has been closed for needed revisions from the OP because: 1) Questions about how to program are off-topic, but questions about team process are potentially on-topic so long as they're from a project management perspective. 2) It's unclear what the actual question is. If the question is updated, it can be reopened by the community. – Todd A. Jacobs Jun 07 '21 at 13:08
  • 1
    Your cons are probably fallacious. One of the most common arguments against this way of working is people working on existing code bases say it only works with new products and people working with new products say it only works with existing code based. For budget, developers don't get paid by productivity. They are either hourly or salaried. Most individual contributors are delighted with less obstacles in their way. – Daniel Jun 07 '21 at 13:33

1 Answers1

4

What you describe is called Mob Programming:

Mob programming (informally mobbing) (aka. ensemble programming) is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.

https://en.wikipedia.org/wiki/Mob_programming

Some companies do all the work mobbed, this time-lapse video shows this concept for multiple teams (including business people) at the same company: A day of Mob Programming 2016 (3 mins - Youtube)

If you do true mobbing like the video above, you get another efficiency benefit: No more meetings!

Personally I have had great experience with promoting mob programming in my teams. Most of my teams used it as a tool and switched it with the Swarming pattern. Depending on the context, complexity, uncertainty, knowledge-sharing needs they switched between Pairing, Swarming and Mobbing. Working solo was not done in our culture.

Why do most programmers work solo? Working together in groups/pairs needs certain social skills that a lot of technical people never developed. You could start practicing mob programming by doing a bunch of kata sessions from the Coding Dojo Handbook. Another method to try is technical agile coaching from the book Technical Agile Coaching with the Samman method.

The slow dev environment problem you describe sounds more like an architecture problem. There should be no need to rebuild the whole product if you decouple its components. This is also why you should refactor legacy projects, read Working Effectively With Legacy Code.

Niels van Reijmersdal
  • 5,553
  • 20
  • 32