Pair Programming at a Startup: time sink or saviour?
henrysztul.info
Pair Programming at a Startup: time sink or saviour?
1–10 of 27 posts
Re: Pair Programming at a Startup: time sink or saviour?
#2I'm the happy partner in this week of peer programming. Great post and great results
Re: Pair Programming at a Startup: time sink or saviour?
#3Nothing wrong with pair programming, but it sure is easier to be "a profitable company that had two programmers sitting in front of one computer, writing code, together" if the company charges by the hour!
Re: Pair Programming at a Startup: time sink or saviour?
#4Re: Pair Programming at a Startup: time sink or saviour?
#5I'm a fan of 'Plan together, implement independently.'
I don't need someone looking over my shoulder hunting for bugs while I program. What I need is someone to bounce high-level ideas off of so that I don't get paralyzed by indecision, or overlook an important edge case.
Bad design decisions concern me a lot more than a bug here or there.
In my experience, planning with someone else away from the computer, and then implementing is as fast (and usually faster) than sitting down at the computer and trying to bang something out from scratch.
When you do things this way you don't really need to have another person there because you've already agreed on all the important details.
Re: Pair Programming at a Startup: time sink or saviour?
#6Also relevant: http://en.wikipedia.org/wiki/Pair_programming#Costs_and_bene...
Studies have found reduction in defect rates of 15% to 50%
Correlation does not equal causation...other practices that usually accompany teams that pair include continuous integration and a strong focus on automated testing.
Re: Pair Programming at a Startup: time sink or saviour?
#7What is missing in most pairing debates is the amount of pairing day to day being discussed.
Periodic pairing can be a great team building exercise, way to mentor someone, and a great way to be exposed to different programming workflows & tools. This idea doesn't seem very novel to me and hardly deserves it's own terminology, blog post, or article.
Personally I believe "pair all the time" is what is controversial and in my experience excessive. Other then commercial pilots, I don't see other industries where experts always pair.
Also, if 2 people are better then 1 person...why stop there...why not have tri-coding or quad-coding?
Re: Pair Programming at a Startup: time sink or saviour?
#8> So the question posed here, is peer programming a time sink for an early stage startup? No.
> That being said peer programming is just another tool in an arsenal that startups should use in appropriate situations.
So the answer is, "maybe". Neat.
Re: Pair Programming at a Startup: time sink or saviour?
#9I'm a fan of 'Plan together, implement independently.' I don't need someone looking over my shoulder hunting for bugs while I program. What I need is someone to bounce high-level ideas off of so that I don't get paralyzed by indecision, or overlook an important edge case. Bad design decisions concern me a lot more than a bug here or there. In my experience, planning with someone else away from the computer, and then…
I agree with this - whenever I see that a company has actual pairing stations (computers with mirrored monitors and two keyboards and two chairs) I tend to shy away.
However, I still think everyone should have their OWN whiteboard, to enable precisely the conversations you mention. Easy enough if you have cube walls, but I've never seen a good whiteboard story in newfangled open-plan startup offices.
Re: Pair Programming at a Startup: time sink or saviour?
#10Emergent peer programming is the best. I've done 2-3 instances of it over the last 3 years and it definitely felt like we truly moved mountains during those couple of hours.
One time we wrote a quite complicated graph-based algorithm (as in, lots of bug potential, but it turned out bug free) and the other two times we fixed bugs that hounded us for weeks in just one session.
I definitely feel like it works best in those situations when both people can complement each other somehow. If it's just a junior/senior person it will probably not be very useful for the senior person (note I mean a true junior here with little programming experience, not just some non-senior engineers).