Skip to main content
Engineering LibreTexts

3.2: Why is Design Important

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    Why Design?

    So often, especially as we are learning software development, we tend to look at a problem and simply start coding. That is a very poor habit that almost every student falls into. We should first think about what the problem is we are attempting to solve, what are the requirements we are given, how can we break the problem into the smallest pieces that make sense.

    Why do we need to worry about design? As a software developer throughout my career, I get it that writing code is a whole lot more fun than writing some design document that is going to tell me what I have to code. However, as we craft our code we must know what we are doing, where we are going, and when we have arrived. This becomes even more important when we begin to develop code with a team, where each person is working on a different portion of the project, and the pieces all need to work together.

    Let's take building a house as an example. I have paid contractors on a couple of different occasions to build a house for me. He always shows me the blueprints, explains how all the rooms are situated in accordance with one another, how the electrical wiring is going to be run, how the plumbing all ties together. All the components are defined as to location and purpose. I would never let a contractor tell me, "I have done lots of houses, I know how this all works. We will start from the foundation and just build it up from there." That is a recipe for disaster. What happens if they forget to put in the bathroom - they have to tear down some of their work and redo it so that it is correct according to what is was suppose to be.

    Let's say the builder shows up, and you ask to take a look at the blueprints. “I don't need any blueprints?” he responds. “I have been doing this a while and I know what I’m doing. I don’t need to plan every little detail ahead of time. This is a two-story house - right? Not a problem - I just completed a one-story house last week, I’ll just start with that idea and work from there.”

    So, let's just say you are able to get past your amazement and allow the builder to begin building your house. As he progresses with the project you begin to notice things aren't quite right, the plumbing appears to run outside the house instead of inside the walls. You immediately question the contractor about this oddity. He replies, “Oh - yeah. I sorta forgot to leave space in the walls for the plumbing. I got all excited about this new drywall technology that I completely spaced out the plumbing. But hey, it works just as well outside, and that's what matters, right?". 

    As you walk through the completed home, you notice that the kitchen lacks a sink. The builder again excuses himself by saying, “We were almost done with the kitchen when we noticed there wasn’t enough room for the sink. Instead of starting over, we just added a separate sink room over here. That works okay, right?”

    You would never allow that to happen when building a house - and we should not make similar mistakes with the software we are building. Even simple programs need to be deliberately designed so that we don't have to go back and redo portions of the code because we forgot something. We will take a few pages to discuss some design concepts and ideas, before we start to talk about coding.

    This page titled 3.2: Why is Design Important is shared under a CC BY-SA license and was authored, remixed, and/or curated by Patrick McClanahan.