Has design been forgotten? I see no active discussion groups on social media devoted to software design. There are several groups in Facebook on that topic, but they are either dead or devoted to a small group of people. Why the neglect? Design is important because if it’s wrong, you’ll need to restructure (“refactor”) some of your software later when you discover that your progress is blocked by your earlier mistake.

1. Structure diagrams in UML do not tell you how software operates. Read the next article below to see why.
2. So folks find that UML is not helpful. They know that UML was created by smart people, so they unconsciously assume that UML is the best we can do. And they don’t know of any alternative to UML (such as IDAR). Consequently, developers don’t know of any way to represent a design that they find useful.
3. So they scribble informal boxes and lines on whiteboards and paper instead. Simon Brown states that “I’ve run diagramming workshops for over 10K people around the world, and most of what I see is ‘boxes and lines’ rather than UML.” This survey of nearly 400 developers shows that only 9% of them use “pure” UML diagrams; the rest are informal.
4. To make the situation worse, today’s agile techniques downplay design, discouraging people from creating thorough designs. In fact, some agile devotees are promoting “emergent design”, which in practice means that design is done concurrently with coding. That’s like building a house with no plans! Those of us who are experienced can see the folly of that, as described clearly in this article by Hayim Makabee.
5. Consequently, design is sloppy and incomplete, causing messiness and rework later in the project.

I like to say that “Design is the tail that wags the dog” because a small change in design can have a big effect on implementation. This is not to say that you must design everything at the beginning of the project. Large software always consists of multiple executables and subsystems, and it’s fine to delay the design of some of them while working on others. But the interfaces among them need to be defined first, which means the overall design (architecture) must be carefully created at the beginning. Then, within that framework, you can use an agile process to interleave designing and coding. But those interleaved designs must be done well to avoid rework when coding.

What’s the solution to our neglect of design? We need to fix the root cause: UML does not tell you how software operates. So let’s replace the structure diagrams in UML with something useful. Something that tells you how the software works. IDAR graphs are a good solution. Click here to return to the main page to learn about them.