2 ms·
I've been pair programming since the 80's - long before the practice had a name. Bottom line - pair programming creates a higher-quality result in less time. I
by taylodl 5y ago
I've been pair programming since the 80's - long before the practice had a name. Bottom line - pair programming creates a higher-quality result in less time. I can't state it any more succinctly than that.
The higher-quality result bit is nothing to sneer at, either. Two minds are better than one. That means it's a better implementation having fewer bugs and fewer edge case surprises. These are things that all drive up software development costs.
You know what's costly? Shipping buggy software. Especially back in the day when you had to distribute software via physical media that had to be shipped to the user. Things get even more complicated when the software is being used in a mission-critical process needing to run 24x7. Outage windows can be difficult to find.
So sure, if you're creating software nobody really cares about because it really isn't critical to anything then I guess pair programming might be overkill. But who wants to work on such software?