Jason’s Laws of Development
As a developer I realise there are some fundamental laws that must never be broken. Below is my summary of these laws. (I would number them, but they all deserve to be Number 1)
- Code that was written, but never committed to SCM was never written
All code, no matter if it is just a quick script to change the colour of four images, to add three C-Name records to a DNS host, or to handle nuclear missile launch protocols, needs to be added to Source Control.Code that isn’t in source control can’t be trusted. Is this the final version? Is it production ready? Was it just saved here for use later? What the hell does this code do? All these things are handled by the context provided by SCM – sure, comments are good, but SCM is better.
- Never go live with ANY modifications on a Friday
No matter how well you test your code, how amazing your unit test coverage is, or how good your QA process is, something will go wrong, and you’ll be fixing in on Saturday afternoon.
- ALWAYS comment your code
You may be the only one to ever touch the code, but comment it anyway. Even the most seasoned developers forget what they were thinking when they wrote that function 18 months ago. The more obscure your code/function, the more detailed your comments need to be. If you’re doing something that breaks with standards or conventions, document why. If something needs further thought and planning document how. You don’t need to comment everything, just the things that would make someone else ask questions if they looked at your code. And your comments should be good enough that a non-technical manager could understand what the process the code follows.
- Code for the future
Never assume that this code will only be in use for the next few hours, days, weeks, or months. Plan for your code to be in use forever. 90% of the time you’ll be right, if you write the code well enough. And most of the time the code you write for a company today will be in use long after you’ve left the company, and then some other developer will be looking it over, and if you’ve done a good job, they will be blessing your name, and singing your praises. If you’ve written poor code, they will want to hunt you down and do things to you that have been banned under the Universal Declaration of Human Rights.
If you can fix that hack or write that comment about the hack now, do so. You never know when you will be taken off a project. Or let go. Or hit by a bus. And the last thing you want is the next developer who touches your code swearing a blood oath that he will end your genetic heritage for the crimes you have committed in your code.
- Never use code snippets you didn’t write if you don’t understand them 100%
You’re responsible for all the code you implement, not just the stuff you write. This goes for those jQuery plugins you implement on your site. You don’t want something dialing home when it shouldn’t be. Check your code, and everything else you use.
- Where possible, get a peer review of your code
A second pair of eyes across your code will help spot errors in logic. This can significantly reduce the technical debt you build up as you add code to a project.
I’ve been guilty of not following these laws in the past, and have come to regret not doing so. The time saved by skipping a comment when I understand the code I have written is minimal
compared to the amount of time spent debugging said code 12-18 months later when something elsewhere in the code base changed and broke the uncommented code. I’ve also used plugins that turned out to have backdoors in them, so now I check everything I implement, write and use.