Purpose
My goal in compiling the tips and tricks I've learned into Effective Software Engineering (ESE, pronounced "easy") is to help spread my knowledge, experience, and mistakes, to a broader community that more than likely may not have formal software engineer training. But don’t let my tips and tricks fool you, there are exceptions to every rule. Effective Software Engineering is not meant to be a strict set of rules that guarantee success. Software engineering is just like any other science or engineering discipline in that many decisions require a careful balance of the advantages and disadvantages to one, two, three, or more solutions. The tips and tricks here are general concepts that will improve the project or code you are working on or improve your software development expertise. These suggestions are based purely from my previous experience that I have found beneficial on a non-trivial number ofoccasions.
I want to spread my knowledge, experience, and most importantly my mistakes. A lot of times a well-engineered solution takes time. A lot of time. There is time spent on designing what the code will look like, meaning what classes/object will be created and what will they do and not do. There is time developing interfaces, both externally facing and internally facing interfaces and how they interact with other bits of code. There is time spent on implementing the code, making sure the code does not have "feature creep" or have the potential for feature creep. And lastly, the most time spent in a solid software solution is in the testing. Ideally there should be unit tests, integration tests, and high- level system (or end-to-end tests). Although everyone can agree that comprehensive testing is good, the amount of testing that actually takes place is almost always less than comprehensive. This results in bugs found during operational processing rather than in a controlled development or testing environment.
Most tips and tricks discussed here are meant to be "quick wins", meaning each recommendation should take less than a week to implement and test, and in some cases just a few minutes. These quick wins are things I've compiled over the years as a way to defensively protect the code before bugs are discovered during testing, you might even consider them to be good habits. I've certainly made my own mistakes that have caused bugs in production environments. But by making these mistakes I've matured as a developer who can now spot areas that will cause problems in production environments.
Another reason why I am creating ESE is because a formal software engineering project can be a big and complicated endeavor, but it does not have to be! A formal process that is agreed upon by all developers, managers, customers, and everyone in between can be a really powerful tool. However I want these quick wins to help spread the word that good software doesn't have to be created by someone with formal software engineering training on a team of only software engineers. Anyone can learn to write code, learning to write great bug-free code takes a bit more effort. Formal training helps, but it is not absolutely required. Hence I am giving you my secrets in hopes that you too can learn from my mistakes and build bug-free code!
And lastly, always think about the future of the code rather than a strict process. In my experience, the code will outlive the developer. At any given time, new members join a software project and old members leave. The code stays around making new team members inevitably responsible for the mistakes of their predecessors. It is important for both new and veteran team members to constantly think about what is best for the project. Can I just slap together a little script and push it into the production system? Possibly, but I really shouldn't. The script should be well thought out, various edge cases should be accounted for, and testing should be automatic and repeatable. Without this, bugs will rear their ugly head at the worst possible time.