Applying the 4 R's of conservation to Software Development

Refuse, Reduce, Reuse and Recycle. It works to reduce landfill, It also works to ensure our code and documentation stands the test of time and do not end up in the virtual landfill.

Hopefully you'll see that applying each R will make it easier to apply the others.

Refuse
Do not write code you don't need to write. This applies at different levels, here are some examples

• Before starting to code, analyze the problem. Not every problem gets solved with automation.
• Before automating a process, ensure it has been properly engineered. A bad process automated is still a bad process. The resulting code will be harder to maintain as people may require drastic changes when they find problems with the process. And in a worst case scenario, people won't be able to change the bad process because they depend on the system, eventually scrapping the process and the software.
  
• Always verify if you need to write new code or if something else already exists. This is: Don't write code that already exists just because you don't understand or like the existing code.
• Avoid automating one-off tasks or tasks which take longer to automate than the time they save. However, this is a recommendation where one needs to balance being lazy (not writing unnecessary code) and being replaceable by ensuring people can do what we do once we leave. So, I make an exception for things that are part of a formal process and maybe hard for other people to understand.
  

Reduce
When it comes to code, less is more. Less to maintain, less opportunities for bugs to creep in, easier to extend.

• Don't write code you "may" need. Write it as you need it. This is also called YANGI (You aren't gonna need it)
• The less code you write, the easier it is to refactor later as new needs arise.

Reuse
Reuse existing code. The likelihood that this is the first time you have faced a particular problem or that you are the first person facing a problem is fairly low.

• Search around for existing code, either in the form of libraries, frameworks, the internet and your own code.
• There are many new challenges in each project, by leveraging existing code, you can focus on the new challenges, and if by looking at the existing code you find it can be improved, then Recycle it.
  

Recycle
The fourth R encompasses four other R:

• Refactor existing code: As your change your code, refactor it to ensure it remains as clean and simple as you can. It is a virtuous cycle where it will be easier in the future to apply the Rs of conservation.
• Refurbish:  As you refactor code, make an effort to leave it "as new". This includes removing old code, not just working around it.
  
• Repair: Eventually operating systems, libraries, standards and needs evolve, breaking code that used to work. Frequently I see people doing back-flips trying find ways to keep the old environment when it may be easier and faster to fix the code to take advantage of the new environment.
  
• Re-purpose: Whenever possible, refactor for Reuse. Identify patterns that emerge as you reuse code to create libraries, frameworks or simply to eliminate redundant code. Examples of this are creating Classes and functions from "in-line" code, introduce dependency injection, expose extensible interfaces and many others.
  

You will see that if you and your team follow these R's, you will end up writing less code and having a cleaner code base.

(I've updated this post which was originally published in April 2014)