Perfection is a verb

December 30, 2012

Ok, this sentence sounds like a fortune cookie. Maybe I’m turning buddhist, but I love it. And it  applies especially well to software development. As a craft based on human interactions, software development is a set of compromises. There’s no such thing as a best practise, a definitive process, or a methodology that works for all contexts. I don’t even understand how words like agile and process or methodology can have ever been put together in any mind.

Agile and lean are approaches that work the best according to what we know today. But they are just containers of values and practises that constantly evolve. They don’t tell you what words to use in discussions, or what lines of code to write for every single situation. They need to be adapted to every context. Scrum and lean startup by the book might be good enough to design a simple shopping cart, but not necessarily to design a car, a distributed NoSQL database, or a nuclear plant software complying with all required regulations.

You always need more than what you can learn in trainings or books. Your situation is always unique and new. If it’s not new, why bother doing it? If you didn’t need to adapt the framework, why would scrum define the basic team around the opposite powers of dev, backlog, and test? Why would lean be based on kaizen in the first place? A set of definitive rules, a process, would be enough.

In the end, you always need to adapt the way you build, collaborate, understand each other, find solutions, analyze gaps, code… and to get better at it. Always. There’s no end to getting better. Because you can always be better, and because the context keeps evolving. And that’s what I love about it. You always can and must do better. Everytime you’re not trying to get better, you’re getting a bit closer to the death of your team, project, organization, company. The world won’t wait for you.

So perfection is the goal, but you can never reach it. How exciting! That’s what the best approaches known so far explain to us right from the beginning. You need to find the right compromise, for every situation: test coverage vs test campaign maintainability, code performance vs readability, taking the time to discuss and understand each other vs saving meetings, writing just enough documentation vs focusing on working software, self-organizing teams vs facilitating their progress, releasing features vs stabilizing the product… There are hundreds of parameters you need to balance. And you always need to tweak the buttons as the situation evolves.

In the next posts, I’ll try to talk a bit more about the tradeoffs we are faced with day by day. What the books don’t say, and the concrete problems they don’t give solutions to. I’ll try to describe the approach we’re taking to oil the wheels. I hope it will save me the shrink.

Written by Antoine Alberti Posted in agile, kanban, lean, scrum, XP