How to make your Software Development experience… painless….

Working at all forms of organizations (from large software development oriented to niche start ups to academic labs), I have noticed that people tend to make life much harder for themselves than it honestly needs to be. Hence, I will use this article to explain how YOU can make your software development experience… less painful than it should be.

Job Schedulers

If it is simple, tedious and obnoxiously repetitive, chances are you can automate it. If you are a Unix user (like the majority of the programmers out there… I hate Windows…), you will have access to cron jobs. The software utility cron is a time-based job scheduler in Unix-like computer operating systems. People who set up and maintain software environments use cron to schedule jobs to run periodically at fixed times, dates, or intervals. Learn the Unix crontab command.

Automated Testing

If you alone or multiple individuals on a team are independently developing the same code base, chances are that someone will introduce some form of bug into the code. Usual procedure is spending hours tracking down that minuscule bug in the entire code while crying in a fetal position (if you have not cried enough, chances are you are not a real programmer). There are plenty of options out there in terms of automated testing. Unit tests are very common. JUnit is available for Java users and the unnittest library for Python developers. However, it is possible for someone to forget to properly run the unit tests on the team before pushing codes into production. In order to avoid such mishaps, automated tests are important. While you can use crontab to run automated tests, I would recommend using something more professional like Jenkins. Jenkins allow you to schedule tests, pick specific branches from a version control repository, get emailed if something breaks and even spin container images if you wish to sandbox your tests.

Containers

Sandboxing is an essential part of coding. This might involve having different environments for various applications. It could simply be replicating the production environment into development. It could even mean having multiple production environments with different software versions in order to cater a much larger costumer base. If the best you have in mind is using a VM with Virtual Box, I am sure you have noticed that you either need to use the exact same VM for multiple rounds of tests (terrible DevOps hygiene) or re-create a clean VM for every test (which may take close to an hour depending on your needs). A simpler alternative is using a container instead of a full on VM. A container is simply a unix process or thread that looks, smells and feels like a VM. The advantage is that it is low powered and less memory intensive (meaning you can spin it up or take it down at will… within minutes). Popular containerization technologies include Docker (if you wish to use just 1 container) or Kubernetes (if you fancy orchestrating multiple containers for a multi-server workflow).

Version Control

Imagine pushing your code to production. And it works! Perfect. No complaints. Time goes on and you keep adding new features and developing it. However, one of these features introduce a bug to your code that badly messes up production application. You were hoping one of your many unit tests may have caught it. However, just because something passed all your tests doesn’t mean it’s bug free. It just means it passed all the tests currently written. Since it’s production level code, you do not have time to debug. Time is money and you have angry clients. Wouldn’t it all be simple to revert back to a point when your code worked??? That’s where version control comes in. In Agile style code development, the product keeps developing in bits and pieces over an indefinite time period. For such applications, some form of version control would be really useful. Personally I like Git but SVN users still exist. Git works on all forms of platforms like GitHub, GitLab and BitBucket (each with it’s own unique set of pros and cons). If you are already familiar with git, consider taking a more Advanced Git Tutorial On Atlassian. An advanced feature I recommend looking up is Git Submodules, where you can store specific commit hashes of multiple independent Git repositories to ensure that you have access to a single set of stable dependencies.

Design Patterns and Code Smells

When people start out as self-taught programmers, a lot of the times we think about creating an application that simply works. It works, perfect! ONTO THE NEXT VICTIM! However, once we try to scale up, all sorts of random issues start showing up. Poor coding practices, lack of documentation and tight coupling. In order to develop a more flexible, reusable and maintainable code base, it is important to understand the basics of Design Patterns and Code Smells. A book that I highly recommend reading is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. SourceMaking.com is also a very good reference site with examples in Python, Java and C. I have already covered some examples on a previous blog: Software Development Design Principles

Commenting

Finally, the most obvious way to keep your Software Development process from going out of hand is by having some level of documentation. While it is nice to have multiple PDFs with detailed documentation of every tiny function and update them as the codes evolve, chances are that it won’t be practical. At a high pace and high pressured Software Development environment, even the most disciplined developers will face some level of mishap. The best way to document codes is by commenting in the script. While people develop the script, the comments will change. There are special commenting rules for different programming language. As a Python programmer, I heavily rely on PEP8. An important thing about commenting is that it should be obvious. If you need a lot of comment to explain a simple piece of code, chances are your code isn’t well written (a very common Code Smell). Think of commenting as telling a joke. If you need to explain it, it won’t make anyone laugh.