Categories
- Agile (6)
- Architecture (1)
- art (2)
- Big Data (1)
- books (11)
- Cars (1)
- Change (9)
- common sense (3)
- Contracting (1)
- Cool (1)
- Design (5)
- development (1)
- emotions (3)
- entrepreneurship (2)
- google (1)
- great quotes (2)
- happiness (1)
- innovation (3)
- IT (8)
- IT Architecture (3)
- Knowledge Transfer (2)
- leadership (3)
- Lean (1)
- links (1)
- literature (1)
- lyrics (1)
- management (9)
- Media (1)
- Negotiating (1)
- networks (1)
- people (5)
- Personal Improvement (8)
- planning (5)
- productivity (3)
- Programming (1)
- Project Management (23)
- Projects (1)
- psychology (3)
- Requirements (5)
- Risk (2)
- scrum (2)
- strategy (6)
- struggle (1)
- summer (1)
- teams (5)
- Test Automation (3)
- thinking (5)
- Training (2)
- Travel (1)
- waterfall (4)
Tag Cloud
Agile
Architecture
art
Big Data
books
Cars
Change
common sense
Contracting
Cool
Design
development
emotions
entrepreneurship
google
great quotes
happiness
innovation
IT
IT Architecture
Knowledge Transfer
leadership
Lean
links
management
Media
Negotiating
people
Personal Improvement
planning
productivity
Programming
Project Management
Projects
psychology
Requirements
Risk
scrum
strategy
teams
Test Automation
thinking
Training
Travel
waterfall
Pair Programming
Posted by Rich Crowley in development, Programming
There’s an interesting new model being used in the software development space. It’s called Pair Programming. It works pretty much the way it sounds. Two developers working on a single codebase together. Here’s an article that provides some background info.
I like the idea, but must admit, haven’t tried it. To me, it sounds like a good fit in companies where new technology is being introduced that directly affect developers. (By that, I mean that if a new piece of infrastructure is being introduced, that requires little code to be written, this model may not have such a nice fit).
I have worked on several projects over the years that introduced some new technology that required one or more developers to get up to speed with it quickly. For example, a report-generating IDE, some scripting, etc. Often this meant working with a vendor expert in the new language or platform. Too often this resulted in the vendor doing the lion’s share of the work with a less-than-optimal degree of knowledge transfer occurring. I think using a pairing strategy, while perhaps slowing the initial deliverables down somewhat, may have been a good approach.
I also really like this approach for getting new developers up to speed on a given language or platform in companies that already have some developers established on it. This may sound a bit like mentoring but I think Pair Programming takes it a step further which could improve productivity more quickly than mentoring does.