My great-granddad, Vet Bradford, was the foreman in charge of digging a tunnel through a mountain in the 1950s. There was a stream of water on one side of the mountain, and a really thirsty town on the other. To speed things up, he had two crews digging on each side, with a plan to join the tunnel in the middle. Obviously they couldn’t just start digging and hope that the two tunnels would meet. The likelihood of failure would have been high, not to mention all the time and resources they would have wasted. Luckily the town was smarter than that – they hired an engineer to survey the mountain and gave them detailed plans of exactly where, and how to dig.
A few years ago, we implemented a new site feature at Ancestry.com that turned out to be a lot like blindly digging through a mountain. Like my great-granddad, in order to speed up development, we worked on it from both sides – some of us worked on the backend service, while others worked on the frontend website. Unfortunately, we didn’t do the proper planning and engineering that we should have. Those working on the backend made different assumptions than those working on the frontend. When we tried to join the pieces in the middle, we couldn’t connect them. We were forced to sit down and hammer out a design. We then had to go back and re-factor most of the code. We realized that if we had only done the design work up front, it would have saved a lot of wasted time. From that point forward, we implemented a new process of creating a formal design for every new feature. This process evolved and eventually became one of the most helpful tools I have used throughout my career as a software engineer. At Ancestry.com we call it Dev Design.
When we begin work on any new feature, we begin with a single task – the Dev Design. Its purpose is to plan out how the entire feature should be implemented and to break it in to manageable tasks. One developer creates the design as an initial proposal, and then reviews it with the team. They discuss and rework the design until they are satisfied that they’ve come up with a really good implementation plan. Once the design is finished, coding it up becomes almost as easy as following a bulleted list because all of the guess work has been removed.
Here is a very simplified example of what a Dev Design might look like:
Some of the benefits we have seen from following this process include:
- Faster implementation of features
- Less re-factoring and bug fixes because all use cases are accounted and designed for up front
- The code base stays clean, consistent, and maintainable (If you’ve ever had the experience, you know it’s a pleasure to work in a clean code base)
- Multiple developers reviewing the design leads to better code
- The whole team becomes familiar with the entire code base, enabling them to work in one area of the code just as easily as another
- Team members are able to broaden and improve their skills, and learn from each other
- The broader team comes to agreement on the design patterns used, naming conventions and coding standards
The tunnel my great-granddad helped dig was completed on Dec. 27, 1951. The two tunnels didn’t come together perfectly. They missed exact alignment by the width of the tunnel plus 18 inches – a problem easily solved by a stick of dynamite. When we create and follow a Dev Design, we don’t always end up with a perfectly smooth implementation, but it’s almost always close enough that a minor tweak or two will get us there, instead of a major code re-factor.
I encourage you to put more of the “engineer” in software engineering by trying out the Dev Design process to see if your team realizes the same benefits that we have.
