Is this glass half empty or half full?
There’s normally more than one way to interpret a situation, but we often forget that the situation itself may be under our control.
I often find my clients have backed themselves into a corner by accepting an overly restrictive understanding of what they’re trying to achieve. They will tell me, for example, that this story is too big BUT that it can’t be split, because then it wouldn’t deliver value. Or, they might be saying that there’s no point writing unit tests BECAUSE the architecture doesn’t support it. Or even, it’s not worth fixing this flickering test, because it ALWAYS works when they run it locally.
I encourage them to rethink the situation. A slice through that story may not deliver the final solution the customer needs, but it will act as a small increment towards the solution. Minor refactorings are usually enough to make a section of the code independently testable. That flickering test is undermining any confidence there might be in the test suite – fix it or delete it.
Don’t try to put a spin on a half-full glass – rethink the glass.
Instead of asking if the glass is half-full or half-empty, use half a glass.
(It turns out that wittier minds than mine have already applied themselves to this proverb – here’s a bumper collection.)
Leave a Reply