Posted by Brian Bradford on September 10, 2013 in Development, Inside our Offices

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.

Vet Bradford (center) with part of his crew.
Vet Bradford (center) with part of his crew.

A few years ago, we implemented a new site feature at 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 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:

Comments - blog post

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.

Brian Bradford

Brian Bradford is a senior software engineer at He joined the company in 2005 and has enjoyed moving around inside the company to work on a variety of projects and technologies throughout the years. He enjoys finding creative ways to solve difficult engineering problems. He likes reading, softball, card games, watching a good sci-fi flick, and most of all spending time with his beautiful wife and children.


  1. Craig Battrick


    This is going to sound like a lecture, but it amazes me that we don’t know what we know. There is a discipline called Requirements Management that teaches how to do what you figured out the hard way. Before I joined Fold3 (a subsidiary of Ancestry in Lindon), I was a Requirements Manager at Sprint, We started with business requirements and translated those into system, user, and technical requirements. Not a line of code was created until the project team understood the requirements and had the same mental image of what the final product would look like and behave like. Wikipedia has an excellent introductory article on the topic.

  2. Brian Bradford

    Thank you for your comment. I would have liked to explain a little more about the Dev Design process we use, but they wanted me to keep the article brief, so unfortunately I couldn’t go into as much detail as I would have liked. Our Dev Design process is not meant to be a full requirements management process. It happens after the requirements have already been completely finalized, understood by the team, and broken down into bite-sized stories. It’s a very lean process that allows the team of developers (and only the developers) to come to agreement on code structure, design patterns, and naming conventions. It’s more like a code review, but before any code is actually written. In fact, we have found that in most cases code reviews aren’t even necessary if the process is followed correctly. I would say that at most our Dev Design process could be considered just a small subset of the Requirements Management process. Dev Design definitely isn’t a unique new process that we invented, but we have tweaked it and streamlined it to something that has worked out really well for our team and our code. Thanks!

  3. Jin Lee

    A Great blog!, I think the dev design is the best thing that our team have adopted from you and Deven while working together on IIV. I think we’re all a little skeptical in the beginning about whether it would really help but now all members in my team would agree it has been most crucial part in our development process. It makes us think twice and code once. And it helps everyone in the team on the same page. I found it much more efficient than individual code review in terms of reviewing the design and sharing the knowledge. As you mentioned in your comment, it’s not something newly invented but it didn’t come easy for us. It requires a lot of practice to hit the sweet spot between the high level design and the detail. I also found as we all get better at dev design, the rest of the development follow very easy. In other words, as far as we get the dev design done right, it can’t really go wrong. Thanks to Dev Design, our development process is much more streamlined and there is a lot more collaboration going on between the team members since it allows us to break a story into tasks logical way and everyone is involved in reviewing the design document before start working on it.

  4. I second Jin on this. Since integrating Dev Design in our (IIV’s) scrum process, we’ve been reaping these benefits among others:

    1. It took our team into that carpenter’s rule-of-thumb culture where we “measure twice and cut once”. This may sound an overhead but in the end of the sprint we are effectively cutting our coding time in half if not faster. This significantly improved our velocity.

    2. Inclusion – every team member is aware of every story and have an opportunity to provide input even if he or she does not own the story. More importantly, “swarming” on stories becomes more apparent and flows naturally.

    3. Influences how we write more concise stories – If a story is incomplete or vague, Dev Design is blocked until story is clarified. It also makes more obvious on the taskboard if there’s an impediment.

    4. It’s another way to convey and/or propose coding standards and best practices.

    5. Ramping up a new team member have gotten a lot easier.

    6. And oh, did I say it significantly improved our velocity? 😉

    Echoing Brian and Jin, I’d highly recommend other stacks to try this.
    If you do decide to try it out, feel free reach out and we’ll be glad to help.

Comments are closed.