So, yes, diagrams can be inappropriate at times. When are they inappropriate? When you create them
without code to validate them, and then intend to follow them. There is nothing wrong with drawing a diagram to
explore an idea.Agile Software Development: Principles, Patterns, and Practices – Robert C. Martin
What exactly does he mean by this? Isn't UML designed to help plan out how to structure your code before "diving in"? What's the point of using it if you don't follow the diagrams you came up with?
Context: In this chapter, Uncle Bob makes a UML diagram for the Score Keeper of a Bowling game. Then he goes on to develop the program in a test driven manner, without consulting the UML diagram. The resulting program is nothing like the UML diagram, and Uncle Bob comes to the conclusion quoted above.
Best Answer
To properly explain this, we need a short history lesson. In the early days of software engineering, an often used analogy was building a house. An architect and structural engineer discuss plans with a customer and come up with a design. Builders then follow that design to build the actual house. Writing code was seen as the equivalent to building the actual house. Thus, there was a perceived need for up front design before that build could take place. Various graphical design tools were created, with UML being one of them.
The idea originally with UML, was that one would fully design a system with UML, then hand it over to coders to translate that design into code. In reality, this just doesn't work, and led to years of programmers being seen as "implementers", rather than "designers", projects being late, the designs having to constantly change after they were supposed to be complete etc.
The reason is simple. Coding is design. With the house analogy, the code is the architect's drawings. The compiler is the builder who takes those designs and builds a program from them. This realisation then led to agile techniques, TDD etc being born: tools to help improve the quality of that code design.
Just as an architect might produce preliminary sketches to help her and her team visualise the overall design, so a developer might use UML, or other tools, to help visualise the design needed. Just as those sketches aren't blindly followed, so the UML should not be blindly followed. The code design should evolve out of agile iterations and using TDD. LIkewise, just as an architect might build a model of the house to help her and her team visualise the drawings, so UML can be used to help visualise the code structure.
As Uncle Bob says, you can't validate the UML, you can only validate the code. Therefore the code is the prime design documentation and UML, if used, is secondary documenation only.