If you are into software development, you must be used to new languages, new techniques, new codes showing up at your desk more often than you want it to. This leaves you with nagging self-doubts every now and then: ‘Can I cope up with this and stay on my feet?’ Here’s where we suggest you set aside a moment and take a good look at this: ‘fundamentals remain over time. Techniques change.’ So, here in this article, we try to present the fundamentals in layman terms. Hopefully, you can successfully compile it in your coding world.
KISS – Keep it simple, silly!
Kiss – abbreviated as keep it simple, silly (stupid)!!!! Hope the four exclamation marks fulfill its duty of keeping this principle inside your geek head every time you hop on to your code editor. Well, it would be better if you remembered it irrespective of opening your editor as this pretty much applies to every aspect of life, as well. The KISS principle was coined by Kelly Johnson, and it states that most systems work best if they are kept simple rather than making them complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. Keep it simple that it cannot be more simple. What is the payoff? Your code becomes easy to understand, less prone to errors, and can be maintained easily. Not only will you be happy for keeping it simple, but others will also thank you for having kept it simple. With that being said, it is easy to overlook this principle. KISS does not mean taking a rigid compromise on the features- be it internal or external. Keep it simple to an extent where it is elegant. If you make ugly compromises on the features it might become what is the opposite of user friendly and elegant.
Avoid using fancy code snippets just because it is fancy. Evaluate its benefits and the premises inside which the benefits are applicable. Try to avoid the fancy outside its own premises. Complex sounds hard, but simple and elegant is harder. If you think a task is complex and hard to implement, you are most probably right. But it so happens that problems that are intense, and arduous to implement are usually one thing – SIMPLE. So, you better keep it simple, silly!
DRY – Don’t repeat yourself!
This principle is formulated by Andrew Hunt and David Thomas in their book The Pragmatic Programmer that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In other words, you should try to keep up the functionality of a module in one code snippet.
If you see yourself going all WET (writing everything twice) – you are working on your program with a wrong attitude, or you must be a person with obsessive typing disorder. What are the benefits? It is easy to fix bugs when it has to be corrected in only one place instead of many. When a module has to be extended or modified, you can get it done faster. Basically, maintenance becomes easier. Also, when other programmers try to use your program, it increases the readability of its user. When it comes to time, not just the time taken to rewrite but also the time spent on correcting it everywhere, which is a mere waste. This comes in handy especially in big applications where we have multiple hands handling the same program. The interesting part about KISS and DRY is that in a way, KISS is implemented by the DRY. Remember, you Waste Everyone’s Time if you are going to keep it WET instead of dry.
Apart from this, we want to present a few other practices that will get you ahead in the big world’s race.
VERSION CONTROL
Not having source and version control is like buying a spaceship without a manual. You are going to stress out on getting your team together to work on the same project if you do not have source control in check. Without this, there is no better means of getting to the root cause of the error that somehow crept into the code. It makes the overall management a whole lot easier.
DO YOU HAVE TESTERS?
No is not acceptable as an answer. But if you did answer yes, you should really reconsider about how one should not ship products enriched with bugs. It is not permitted to mooch off from the pay you should be allotting for testers. Bugs need a second a pair of eyes to be detected – either your tester can lend them, or your customers will. While it is a matter of seconds when your tester does, it would be a matter of rolling out a new version when it’s your customer. We’ll leave it here.
REGULAR CHECKS ON YOUR BUILD
Breaking a build is beyond treason. You can’t go home without fixing the build you broke. You simply can’t. Mostly because other project members would not let you go home. With daily builds, when the tester points out a bug that a programmer thinks has been solved, you can track it back to the origin-base of the bug and rework it. It is easy to provide versions catering to particular requirements. For example, for beta testing a fairly stable version will have to be presented while your team might be halfway in the progress of fitting in new features into the version.
DO YOU MAINTAIN A BUG DATABASE?
If you think you can hold your bug database inside your head, try reciting the list of things you will need at a grocery store without looking at it. Can you? You better get yourself a bug database and in return, you will stop shipping low-quality code. That is the payoff. By using a database you make them universal, increasing its scope of being solved. Everyone gets to know about the status of the bugs as well. Every bug, not just the two or three you usually remember, but every last one of them gets fixed.
To conclude, you’ve got to train yourself to keep up the good practices as a habit. Even after all the efforts, if you happen to forget the principle and practice, at least remember to back to this blog. We’ll always be here waiting for you to forget (no, kidding!). These practices make your code robust, easy to maintain, and extend.
