Menu
Why Slowing Down Made Us Faster
By Kinya Kaunjuga
Kevin didn’t tell the story like a triumphant headline. He told it the way developers talk—measured, honest, almost reluctant to claim too much.
“It wasn’t perfect,” he said. “But everything we hoped to achieve… we achieved.”
Last year, the Banda developers began something that sounded inefficient: pair programming—two developers working on the same task.
On paper, it looked like slowing down and cutting productivity in half!
Kevin laughed at the criticism. “People say, ‘Isn’t that terribly inefficient? You’re essentially cutting your speed in half.’ And to a certain extent, you are.”
“If something takes four days alone and five days together,” Kevin said, “but now everyone understands it? It’s totally worth it. Because next time, it won’t take five days. It might take three.”
Speed matters at Banda. Every delay means users waiting longer for tools that help them manage their clinics smoothly.
In the beginning, working in pairs felt like wearing someone else’s shoes—technically fine, but slightly uncomfortable with every step.
Keep in mind, these are programmers, they like things so precise that they hold a thought in their heads until it’s right. Now imagine asking them to rotate constantly and pick up someone else’s half-finished thought. And—hardest of all—to explain that thought out loud while it’s still forming in their mind. It wasn’t seamless and it wasn’t comfortable. In fact, on some days, it was neither.
But they were intent to keep going.
Andrew and Kevin would start together, while Brian tackled his own work. Then they rotated—Kevin stepping into Brian’s work, Andrew continuing solo. Brian would later move to Andrew’s work, Kevin carrying forward what Brian had begun. Andrew returned to Kevin, each rotation bringing a fresh perspective without breaking the train of thought.
They kept cycling around until it simply became how they worked.
Then, somewhere along the way, something shifted. Kevin saw it first—not in a moment, but in the numbers (shown in the graph below). Work was moving faster, not because anyone had suddenly become quicker, but because they were no longer doubling back as often. Fewer reversals and less second-guessing. They were arriving at the same place, together, the first time.
Then shared knowledge—this may have been the greatest gift. Before, a feature might belong to someone. “Kevin built that.” “Andrew owns this.” Until, as Kevin put it bluntly, “God forbid the person who developed it gets hit by a bus.”
Pair programming dissolved that fragility. Features belonged to the team. Any one of them could fix, improve, or extend a feature.
Kevin is most passionate about the gains you don’t immediately see—the ones happening behind the scenes.
As the system improved, fewer things broke later. That meant fewer urgent fixes pulling the team away at the last minute. With those interruptions reduced, the team had more time to focus on what mattered most: building the features clinics were actually asking for—which, as Kevin called it, is a blessing: better software reaching more clinics, and the patients those clinics serve.
Just Three Developers and Countless Lives Depend on Them
A former Quickbooks VP sees what we've built—and a reaction that says it all
If the tech talk had you scrolling fast—here are the key takeaways:
Kinya Kaunjuga
Kinya, our corporate storyteller, is an Aggie, and has lived and worked in Africa, Asia and North America. She’s met people from almost every part of the world and believes everybody has a story worth listening to.