Not Sustainable Software Development

Locally there is a group that has put together a number of practices (named Sustainable Software Development or SSD for short) for use in software development projects. I know a number of the people in this group. They are talented software developers who are passionate about what they do and are genuinely searching for how they can do it better (qualities I respect). I do have concerns about the practices though, as I don't see them as sustainable.

Premises:
1. Commercially, at some point, a consumer will stop paying for something if they don't perceive enough value from it.

2. SSD does not deliver value that the consumer (person/organisation paying for the development) can perceive in a timely manner.

Conclusion:
SSD is not commercially sustainable.

The basis for premise 2 is that the daily, primary focus of developers in SSD is to 'refactor' the codebase for improvement, rather than delivering customer visible features. Generally stakeholders use visible features as a significant aspect in their valuation of a project.

The biggest risk IMHO is that I see SSD enabling and encouraging a very developer centric situation. Essentially as a developer you can do a lot of things that you want to do, without having to have an equally balancing consideration of how that will help the business meet its objectives. This is the opposite of the more common situation where the business drives an unachievable workload without consideration of the developers and the quality of their work.

Instead of either of these scenarios, I think we should be aiming for projects where the business values and empowers the sustainability of developers and the developers deliver to both the short term and long term objectives of the stakeholders. A win-win for everyone.

To achieve this, there needs to be a cooperative approach between all parties involved. However, a cooperative approach will only work effectively once trust has developed. To develop trust requires everyone doing the hard yards of demonstrating their concern in meeting the needs of others.

Finally, one of the interesting things I have observed from some practitioners of SSD is their tendency to break their code down into small chunks, which they will attribute to their interpretation of TDD. However I suspect it is more an unconscious movement towards better composability as a means to deal with complexity. The ability to implement a new requirement, that looks similar to an existing one by composing the building blocks of the existing implementation with whatever is actually different about the new requirement is a significant step in managing complexity. Unfortunately most current software does not decompose well, due to the languages we use and the way we use them. Brian Beckman talks about composition and complexity in this video.