Programming is not an easy thing to do, and developers require a significant amount of focus, concentration, and flow to do what they do best. Interruptions will break this flow and slow down an otherwise productive programmer. While environmental distractions can be a source of interruption, it’s also important that engineers don’t interrupt themselves either!
Typical developer attention spans while waiting for a compile is between 30 and 90 seconds. Anything longer than about two minutes will result in broken focus and an opened browser window.
This process needs to be FAST. A decent developer will be writing and running code multiple times an hour, and every second this process takes is an exponential waste of time. A build time of under 10 seconds is best, but complicated software can make this a challenge.
One common approach is to cache already-built assemblies, and only rebuild the assemblies that have related changed files. The Make system does exactly this for C++ project. Tools like gulp have “watch” commands, which can make the build process nearly invisible.
Teams that use automated tests to ensure their code quality will be running their Unit and Acceptance tests frequently, multiple times during development and at least once on the commit step in a Continuous Integration environment.
If the tests in the project take more than a few seconds to run, they won’t be run at every opportunity they should be. Tests that aren’t run might as well not be written at all.
Tests should focus mostly on the code itself; load-testing a database server for every run of the test suite is slow and impractical. Instead, try to use Mock objects for your Unit tests, and keep time-intensive tests separate from the typical test suite.
Changes to the code need to be saved often, and preferably in a place remote to your local development environment to function like a backup. Hobbyist developers might use the copy-and-paste method of version control, making a copy of the current development folder under a different name to track changes and enable rollback. But this process is manual and slow, and because of that, rarely done.
Most modern source control systems are incredibly streamlined to be as fast and as invisible as possible. SVN, Mercurial, and git are very fast command-line applications that will keep versions of every change you’ve made. Commits are kept simple and viewing or reverting to an older version of the project or a single file is a simple and easy thing to do.
More complicated projects can even slow down otherwise fast version control. Git has post-commit hooks that can easily get out of hand and eat up valuable seconds that should otherwise be spent on development. Instead of putting scripts inside the git hooks, try instead to use a service like Jenkins to trigger its own separate process.
Consistent, Automated Deploys
Especially in web development, the deployment or release of the software is a common occurrence that can easily suck up hours of productive developer time. A manual deployment process can introduce missed files, missed servers, or misconfigured environments, resulting in even more hours of wasted time debugging easy mistakes.
Setting up your code to be automatically packaged for deployment is a great first step in making this process seamless. The best development environments are ones where a simple commit can trigger a deployment to a QA environment immediately. This is known as a Continuous Integration pipeline, and takes a lot of the distracting operations work out of software development.
At the very least, making sure scripts exist to deploy your code to each environment can keep a deployment down to a few minutes of automated processes instead of hours of copying and double-checking.
While every project has its own quirks and issues, trying to stick to these suggestions for fast builds, efficient tests, streamlined commits, and consistent, automated deploys will keep your development team happy and productive throughout the day.