Software best practices
- Source control
- Code review
It's the blend of our practices and our culture that makes us unique.
There are a number of practices we use on all projects that we've experienced helps build better software, faster, and more cheaply. Here we explain what practices we employ and how they benefit your project. We talk about code below but these practices apply to any aspect of our development.
What it is: Source code is stored within a shared, central area called a repository. A history of every change since the beginning of the project is preserved there. Each programmer has a copy of the entire repository.
The benefits: Efficiency. Source control gives programmers an understanding of how any part of a project came to be. It gives them a safety net to make necessary sweeping changes.
What it is: Using computers to perform testing.
The benefits: Efficiency and quality. Computers can run a thousand or more tests per minute. A human takes a few minutes per test.
Test-driven development (TDD)
What it is: Tests are written using code before the feature code is written, and then only the feature code needed to pass the tests is written.
The benefits: All code is tested. No time is wasted on writing unnecessary code. Over time a collection of tests ensures that new features don't break existing features.
Continuous integration (CI)
What it is: As code is written by different programmers it is frequently merged into the main product, often immediately. Then the automated tests are ran.
The benefits: New code that is merged into a shared repository early on is most compatible with the overall project. When the merge happens late it takes longer to fix the incompatibilities.
Continuous delivery (CD)
What it is: Software is kept in a state that it can be delivered to customers at any time.
The benefits: New features or critical bug fixes can be rolled out as soon as they're done.
What it is: As soon as the tests have all been run and pass successfully the new changes are pushed straight out to customers.
The benefits: Working features make you money when your customers can use them. Let them use the features the moment they are ready.
What it is: We use the computer to perform all the steps necessary to get your code into production and in front of customers.
The benefits: There are many steps involved in getting a non-trivial project into production. Computers do them quickly, and without errors. This allows us to deploy changes to a project up to as many as twenty times a day.
What it is: When a programmer finishes working on a piece of work by themselves a second programmer looks through the code to ensure it works correctly, fits in with well with the rest of the project, and—if it's a visual feature—that it looks good and affords a pleasant user experience.
The benefits: Increased quality. We find problems before you or your customers do.
What it is: Two programmers working together at the same time on the same piece of code. One will be a driver, typing at the keyboard, while the other is the navigator, keeping track of ideas to check, alternatives, and looking up documentation.
The benefits: There's often more than one way to do something. Two pairs of eyes catch bugs. Knowledge of all parts of a project is shared between a number of people so that no one person becomes a bottleneck.
Programmers work on the requirements
What it is: We encourage all programmers to consider the requirements of the customer before building a feature and to communicate with the customer where any clarification is needed. Programmers suggest alternatives to the customer where they think they can work better or save money.
The benefits: Cost, quality, and efficiency. Because programmers understand the business value of the feature they are building it is more likely to be relevant and useful the first time around. Requirements are not lost in translation.
No QA department
What it is: We do not have roles for quality assurance and testing.
The benefits: Developers take full responsibility for the code they write. The buck stops with them. Features aren't done until they're DONE-done with no ifs or buts.