Everything else in the software development process leads up to this point: writing code. This article is part 5 in a 5-part series explaining maximizing long-term throughput in the development process. Read the other articles for information about why it’s important to optimize for throughput, the role of meetings and communication, managing a development backlog, and managing risk.
Using best practices when writing code accomplishes the following:
-
Prevents regressions, wherein new code causes bugs in old code
-
Helps ensure consistently high development throughput
-
Minimizes technical debt—the long-term consequences of writing bad code that must be refactored in the future
-
Mitigates the risk of error and bug-prone code reaching production
-
Allows developers to work on features instead of bugs
-
Makes the product easier to augment in the future
-
Makes the development and product team happy
Tactics vs. Tools
Below, we outline the tactics we use to write code along with some possible tools. Tactics are the pillars of the process. Tactics change on an infrequent basis (e.g. every several years).
The tools, on the other hand, are mutable. They can and should change as better or more convenient tools and software products become available.
Here are some of the best practices the SmartLogic team ascribes to. Some teams may follow different best practices but this is what works for us.
| Tactics | Tools | Benefits |
|---|---|---|
| Use a source code control system to manage the actual files being produced by the development team. | We use git, specifically GitHub. Other systems exist (subversion, CVS, SourceSafe) but are inferior to GitHub. | GitHub is built on git, a Distributed Concurrent Versions System, or DCVS, which makes it easy to branch and merge code. This makes teamwork easier. Teamwork, in turn, improves code quality. Additionally, GitHub provides a pull request feature (benefits are described below). Even if you don’t use GitHub, some version control system is essential to a team of professional developers. Without a source code control management system, you’re at risk of losing track of which code is current. There are so many good reasons to use revision and version control that there are whole books about it. |
| Ensure another developer reviews and approves code before the code is deployed to production. | We use pull requests to accomplish this. | Using a pull request workflow to introduce changes to production code makes it likely that: The delivered code is clear, because the reviewer—who was likely not involved in writing the code—needs to be able to understand the changes made That the delivered code is correct, because the reviewer has a fresh perspective on the new code, and is—ideally—looking to find any flaws In practice, code delivered this way is more maintainable. |
| Use behavior-driven development (BDD). | We use Cucumber and Capybara for running automated acceptance tests. | Behavior-driven development produces tests that serve as the code specification, which, when done properly, is understandable to a client or non-technical stakeholder. When non-technical people can understand what the developer is trying to achieve, it becomes easy to determine whether development efforts are providing value. In short, BDD fosters communication, which in turn allows the value of development to be maximized. |
| Use test-driven development (TDD). | We use RSpec to write and test application scenarios for Ruby. We use Mocha and Konacha to test javascript. We use JUnit and Android extensions to test Android. We use specta for TDD and BDD on iOS. | Test-driven development, in reference to the general process of writing automated tests before the actual implementation, helps developers avoid code regressions, and permits rapid, confident refactoring. With a robust, thorough, automated test suite in place, a developer is able to produce higher quality code quickly while reducing the number of bugs that get delivered. |
| Use Continuous Integration (CI). | We use Borg (a dedicated CI server), with the Jenkins infrastructure to streamline our integration of code and automated testing. | We use Borg (a dedicated CI server), with the Jenkins infrastructure to streamline our integration of code and automated testing. |
| Pair program | We use a dedicated pairing server. We use tmux sessions to share a terminal window, and we use Vim for code editing. | Pair programming helps to bring developers up to speed on a new project, allows developers to combine strengths, and helps ensure that code is error-free. |
Turning your idea into a product is an arduous process. If you do it right, you will make mistakes, adjust your assumptions, and learn more than you ever expected you would. Whether or not you’re experienced in building products, the right outsourced development partner can help you avoid some of those mistakes, and build a more successful application. If you’re going it alone, find advisors and ask for help and feedback often.
