3 ms·
I think the author is conflating Pair Programming with other concepts. There are no high notes, no thought out design. There’s only the design that could have
by joevandyk 16y ago
I think the author is conflating Pair Programming with other concepts.
There are no high notes, no thought out design. There’s only the design that could have tests written for it, in the time you had to write the tests. The classes look reasonable at first glance, and the methods are seemingly bug free. But the cracks are there, if you know where to look. ...
Eventually, I realized that many of my partners had never worked outside a test driven development process: they didn’t have the same idea of design or architecture as patterns distinct from code. Trying to argue for encapsulation or adherence to SOLID principles is pointless if your partner has no background, let alone hands on experience, with what you’re saying. This goes double when you’re talking about hard-won domain expertise: the more I knew about a subject, the less I could say. ...
The large part of pair programming was doing things in “The Simplest Possible Way That Could Work.” In practice, this meant doing it the way that it had been done previously, with the least possible amount of change. ...
What on earth does any of that have to do with Pair Programming?
- joevandyk 16y agoIt sounds like his biggest beef is the lack of refactoring that supposed to happen after the tests pass. Red, Green, Refactor.
- will_sargent 16y ago> What on earth does any of that have to do with Pair Programming? I'm the OP. What I'm describing is my experience Pair Programming in one organization, and why it didn't work for me. To tell the story, I needed to provide the context and the background to say why it didn't work for me. They're distinct issues, but the only way we could relate to those issues and work through them was through the lens of pair programming. Keep in mind that I'm not trying to say that Pair Programming is a flawed practice in principle, or even that their approach was flawed _in practice_ for the company -- there are other metrics besides code quality that a startup needs to consider if it's going to survive, and sometimes "good enough" code is good enough. I'm well aware that pair programming works very well for some people, and that my experience may not be typical. However, just because my experience wasn't typical doesn't mean it didn't happen.