|
|
|
|
|
by flax
526 days ago
|
|
I, personally, am very much going to push back against pair programming as a default. Being "on" all day, interacting with people is completely exhausting. Yes, I've tried it. I can do pairing for an hour or two, then I'm pretty much shot for any social interaction for the rest of the day. Including at home, which is a problem. TDD sounds great in theory, but in practice most of the time the requests from PMs are incomplete. They may have the happy path mostly figured out, but they have usually given zero thought to corner cases, error conditions, or second order effects. You can't write meaningful tests for these (the most valuable cases to test!) until you go a few rounds of iteration with the PM. And generally you can't explain it to the PM without at least a mockup of the situation. It's often faster to create a barebones implementation to demo than it is to create visual mockups that convey the complexity. And then you've written your implementation before the test anyway. |
|
Walking through mockups and saying "ok, but what happens if I do this" is essentialy the same question as "what are the acceptance tests for this?"
Often that happens in various kinds of meetings over the course of feature development, when it would be more effective to just immediately create the tests up front, which can then go and be developed against. With current tooling, it's actually possible to get the PMs to participate in detail in writing tests. Although that point is often where I have gotten the most pushback.