Three Minute Design

Good design starts small

Software development is an iceberg and if you skip the stuff beneath the surface, it’ll just sink you later. Give me three minutes and I’ll save you enough time to break even on a ten-minute task.

Intentional design is a fundamental component of good software, and we can all do it given the right tools. Software design isn’t some secret revelation a senior developer has while playing Foosball in his office, to be written on stone tablets and distributed to the rest of us for implementation over the next three years. Granted, some projects need design at that scale, but we don’t need to travel that far to get our hands dirty. Software design can (and should) permeate every layer and detail of a project, no matter how trivial.

Now, don’t fire up Powerpoint or schedule a two hour meeting – we’re talking about something easy – the task you just told yourself you actually could do in five minutes, but will likely take a full ten to fifteen from start to finish. Design is too expensive for a task like that, tight? Wrong! This is a job for the ThreeMinuteDesign™, leading to a better, more intentional implementation in less total time. Don’t grab your keyboard just yet. Give me three minutes, then we’ll hit that trivial change with the purpose and intent of a Next Level Developer.

Answer the following questions in your own words. You want to have enough time to think things through and be honest, but not enough time to get stuck.

• What is the problem you’re trying to solve?
• How are you going to solve the problem?
• What cost does your solution introduce?
• Are there other tasks that should be done first?
• How will you prove that you solved the problem?
• Is there a more fundamental problem you could address for a similar effort?
• How could your solution fail?
• What new problems does your solution cause?

Each of these questions should only take around twenty to thirty seconds if you are familiar with your code base and you really were ready to jump in and start coding.

After writing out the answers to these problems, close your eyes, and count backwards from ten while breathing deeply. Attempt to read the design proposal in front of you with a fresh set of eyes. It may be useful to imagine that the proposal was written by (and will be implemented by) a less experienced developer who often makes mistakes (like a time-traveling version of yourself from two years ago). It is not a failure to reject the proposed design, to ask for clarifications, or to escalate review to a different engineer, even for a seemingly trivial task. Do not proceed unless you’re proud of your design. Once you get to this point, you’ll find implementation faster, you will make fewer mistakes, and you can publish your solution with confidence. As an added bonus, you’ve written the meat of a beautiful commit message or pull request description.

Welcome to design-first development.