The Art of Agile Development

Design Is for Understanding

If source code is design, then what is design? Why do we bother with all these UML diagrams and CRC cards and discussions around a whiteboard?

All these things are abstractions—even source code. The reality of software’s billions of evanescent electrical charges is inconceivably complex, so we create simplified models that we can understand. Some of these models, like source code, are machine-translatable. Others, like UML, are not—at least not yet.

Early source code was assembly language: a very thin abstraction over the hardware. Programs were much simpler back then, but assembly language was hard to understand. Programmers drew flow charts to visualize the design.

Why don’t we use flow charts anymore? Our programming languages are so much more expressive that we don’t need them! You can read a method and see the flow of control.

Before structured programming:

  1000 NS% = (80 - LEN(T$)) / 2
  1010 S$ = ""
  1020 IF NS% = 0 GOTO 1060
  1030 S$ = S$ + " "
  1040 NS% = NS% - 1
  1050 GOTO 1020
  1060 PRINT S$ + T$
  1070 RETURN

After structured programming:

  public void PrintCenteredString(string text) {
      int center = (LINE_LENGTH - text.Length) / 2;
      string spaces = "";

      for (int i = 0; i < center; i++) {
          spaces += " ";
      }

      Print(spaces + text);
  }

OK, it’s not entirely true that modern languages make the flow of control obvious. We still run across huge 1,000-line methods that are so convoluted we can’t understand them without the help of a design sketch. But that’s bad design, ...