RES Cost Effective Coding Guidelines

Writing code always invovles trade offs, and there is always a balance to be struck. To help our programmers make good decisions, we provide the following high level advice:

Initially code should be written quickly and simply, and should be easy to understand.

It should solve only the current problem and not potential future problems.

It can contain duplication, and does not need to be easy to change (as it may never need changing).

It should generally not contain abstractions, as it is unlikely that there is enough information to design a good abstraction at first.

Changes tend to cluster in certain files / classes, so when change requests for a piece of code arrive, we can expect more in the future, which gives us licence to spend more time.

We also have concrete information about what the desired change is. At this point we should make the code easier to change, which will probably involve removing duplication and creating abstractions (when enough information has arrived to design them well).

This will often make the code more complex, and at least in places harder to understand, so it is a trade-off.

Once the code has been made easier to change, the desired change should then be easily made.

This quote is from a fuller exploration of programmer decision making, which is detailed in previous articles (Empower programmers and avoid large scale refactors and Making decisions at the right level).

We hope that this advice, along with the other articles, will allow programmers to feel confident in their decisions, and to use their skills to unleash value at RES, and move us towards a future where everybody has affordable access to carbon free energy.