Courage and Trust in Software Development

Bill de hOra writes...

While refactoring is important for codebases that are expected to provide a product dynasty rather than a legacy mess, it's often devalued as mere tinkering by those removed from source code, as it doesn't provide new functionality - it can be very difficult to explain to a non-expert why not adding, or even delaying features now, will help with delivery of features later.

I think there are several ways to approach this devaluation. One is, do things in small pieces whenever possible. A little refactoring following a little vlaue adding is hardly noticeable.

A frequent question I get in the face of this kind of devaluing is, "Should we just do X and not tell them?" My sense is that sometimes may be advantageous when adopting a practice that has been unduly questioned. But my advice is not to make a habit of this. An important goal is to build an effective whole team, and deception in any significant, ongoing, way cannot be effective in the long run.

There is a more positive approach to this kind of behavior. That is to revisit the roles and responsibilities of developers and other stakeholders. In this case, developers have the responsibility to improve the design when they believe they'll get better at adding value in the longer run. Stakeholders having the courage to trust their developers is as important as those developers having the courage to admit they need to go through a significant refactoring for some reason.

Most software development practices over the last several decades have not brought courage and trust into the equation. Making these values part of the discussion is a clear advantage to agile methods and Extreme Programming. Scary, but better to be encouraged to courageously dive into the depths of what will haunt you anyway, even if ignored.