Roughing Things In - Commit small and merge fast as a team

Here at silverorange our team has been growing faster than ever. Getting things done for a deadline can sometimes require letting go of trying to do things perfectly. However when a team has chemistry, even the most stressful timelines can be tackled collaboratively and it’s a beautiful thing. As a consequence of tight timelines and client expectations, a process that developed organically here at silverorange is the concept of “roughing things in”.

Get 80% done by the time the project is halfway through the timeline

One common problem is the illusion that a project is going at a good pace. Then, a few weeks before launch, everyone is panicked because the project is clearly behind. When we start a project, we add a bunch of tasks and as the project continues, a backlog accumulates and gets bigger as the project goes on. Tiny tasks add up and more are created as we uncover all the edge cases once we start testing. But you can’t really start testing until you have something that you can test!

“Commit code that is going to make a difference, but not necessarily be 100% polished. This means a change may not be 100% accurate to the designs or 100% accurate to the functionality. This does not mean merging broken code.”

This isn’t exactly new, as the concept of commit early and commit often has been preached for years. I’m sure we’ve all read about this and nodded along agreeing. Doing this in a team requires a certain understanding and trust. When we “rough things in” there is flexibility to merge code with minor non-blocking issues, but one must ensure there is a task logged to come back for a second pass for more careful code-review.

Say what? Are we saying we commit code that does not match the exact request, and has not gone through extensive review, nitpicked and commented to the point where reviewing becomes an eight hour ordeal?

The process of “roughing things in” starts when a set of code changes (a pull request) is proposed but has something missing or needs polishing. At that point we make it a habit of noting in the pull request what is missing and make it clear to the reviewer what will be completed separately. Essentially more responsibility goes to the developer to communicate this and keep track of these additional tasks. The reviewer also has to feel comfortable knowing that some unfinished work will get done later.

“Why would we want to make pull requests that don’t address the assigned task?”

One would argue it’s a waste of time to divide tasks into separate pull requests, because it requires more overhead writing descriptions and adding the task into project management tools which require even more descriptions. And yes, this does require more upfront time and effort. However, the time spent doing this allows the flow of work to keep moving forward.

The philosophy of only committing working code seems pretty logical. An extensive review process has also been a good way to make sure clean and unobtrusive code is merged to the project. It’s also an opportunity to work more closely with team members and learn from each other during this process. But is this practical when it comes to meeting deadlines?

When we split things up into smaller tasks, there are no hidden massive features hijacked in one PR going back and forth between two people. Some developers may not realize a massive incoming PR may very well change the ways they may be solving their own tasks.

Git commits are fast and easy to recover from if things need to change

“Roughing things in” does indeed expand the project since we are essentially committing “prototypes” and going back to fix or improve things later on. We are doing second or even third passes instead of trying to get one thing done perfectly the first time. But in doing so, we are able to test and uncover problems sooner. Major problems are found out earlier, and the smaller ones are prioritized for later. Once we have bigger problems sorted out at the beginning it’s easier to visualize and estimate how much more is left in the project.

Project Managers become more in tune with the state of the project, understanding how far into development the project truly is. Their role is more involved, understanding what changed and sharing these details with clients in a way that matters to them. There is no longer a reliance on a lead developer simply telling them where things are at. They can see progress. By constantly pushing code, the staging site is incrementally changing and viewable by clients because the project is always evolving in small chunks. Clients are more involved with the evolution of projects.

Evolving ways of software development

At first this may seem counterintuitive, but this method has been working well in projects where we are starting from scratch or is a completely new page or feature. It has worked well in teams with a shared understanding of the concept. This method isn’t the answer to all software development logistical problems, but it’s a start and we have certainly had smoother project launches thanks to the process of “roughing things in.”