There are a couple of practices I value greatly, and which many engineers struggle with, usually for the same reason. One practice is planning for value in small increments, which I discussed a couple of weeks ago. The other is pair programming. The common objection is lack of speed.
Regarding planning, I often find a plan which is logical, but only delivers meaningful value at (or very near) the end of a lot of work. When I ask about a different approach one objection is that any other plan would be much longer and indirect, so couldn’t possibly be preferable.
Regarding pair programming, one objection is also that it’s slow—two people at the same screen can’t possibly write as much code as the same two people working individually.
Naturally, both objections are entirely correct at one level. After all, I’m always talking to technical experts; they’re smart people.
However, in a real world project there are many things we might want to optimise for. Raw speed may seem important in a project (with its deadlines and budgets), but in a project of any length there are other factors which can derail this.
Delivering value incrementally enables us to deal with surprises that the world will throw at us. Unexpected demands (such as a competitor or new research or the economy or another project or a customer or a change of leadership) will often force us to change direction. If we’ve already delivered some value and then we can bank that and make the change without major loss. But if we’ve spent the same effort and not yet delivered any meaningful value then we have a choice of throwing away that earlier effort or not responding to demands. The proposal to deliver value in small increments is about optimising for robustness, or flexibility.
Pair programming results in two people sharing ideas, sharing knowledge about the code, and some learning in at least one direction. Not only is the code of higher quality (ideally more secure, less buggy, more consistent with the rest of the codebase…), we now have two people who understand that part of the code. This practice is about optimising for maintainability, reliability, people being able to move in out of teams, sustainable development, reducing dependency on certain individuals, and so on. We might say it’s about speed in the medium and long term, not the short term.
So, yes, there is a sense in which traditional planning and individual coding are fast and efficient. But that doesn’t mean they are always the best way to do things. It’s always worth considering other things we might optimise for.
niksilver.com 