Friday, 17 December 2010

The Software Development Compromise

I've heard a lot of talk of compromise in our company lately, and the folk talking about it are absolutely right: we have to make a compromise between creating working software to sell and maintaining our codebase. We could spend years cleaning up, re-factoring and polishing what we have, but the reality is that new releases and completely new products have to be created at the same time, or the company has nothing to sell, we make less money and have to shed a load of staff, developers included.

However, I've heard little talk of how and when we make this compromise. What makes for a healthy compromise and what makes for a damaging one? Here are my thoughts on this, and they are simple.

When should we compromise?
We should compromise at the beginning of a project, when we have choices, rather than have a compromise forced upon us by circumstance in the later stages.

How should we compromise?
Actively and consciously. Again, it's all too easy to become a victim of circumstance, and have choices forced upon us through our inaction.

Who should compromise?
Naturally, the compromise should be made by those who are affected, so the developers should be involved in making the choice, as well as those people that are making the business decision. The most important thing here is that developers and product marketing managers make this compromise together, rather than either party forcing the compromise onto the other by their actions. The two points above should help to achieve this.

Finally, we need to remember that if we (as developers) are excessively happy with the balance, then it's probably too much in our favour. Likewise, product managers should also be aware that an outcome that suits them too much is likely to be unhealthy also. As someone once famously said,
Compromise is a solution that neither party is happy with