Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.
The design activities referred to includes the whole range of styles, from the classic up-front design to the emergent design style commonly found in agile projects.
Peoples beliefs differ about to which extent good design matters, but Martin has run into a rather extreme opinion a few times:
Indeed I’ve come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.
The reason that trading design effort for development speed won’t work for most projects is that the system rapidly becomes hard to work with, and the time saved on design activities are soon lost due to decreased productivity.
The trick is to figure out where the design payoff line will be for your particular system before dropping any design activities, but we can only rely on experience and gut feeling to figure it out, since we can’t measure software development productivity.
However, experience is needed to make a good estimation of where the design payoff line will be in a given situation, and Antti Tarvainen pointed out that the lack of experience not only is troublesome when a software development novice has to make the judgement call - it also makes it hard for managers to estimate the economic value of design efforts:
Our software development novice cannot make the judgement about the value of design, because his conceptual model is not rich enough...The problem is, he doesn't know of how much design is worth compared with just writing features without design. Undervaluing design leads to bad code quality and keeping to code-and-fix. Overvaluing it leads to analysis paralysis (in big design up front) or just low velocity (in agile methodologies).
Dennis E. Hamilton (a.k.a Orchid) accredited a couple of common mistakes to making the call without having the required design maturity:
This explains common novice blunders: having an appetite beyond our capability and our stamina. I’ve got the tiger by the tail, now how do I get it into the frying pan? I could have saved my ass by envisioning the endgame first, but I don’t know that, do I? I will be operating somewhere out in the no design region where I don’t deliver any functionality whatsoever. I suppose that has to be somewhere on the imaginary plane above Fowler’s safe-landing territory
This also explains some common management blunders: taking out crushing technical debt without recognizing it and then having no means to ever repay it. Management probably needs to understand software lifecycles and risk management far more than the cybersmiths, even without the skill (and certainly no foolish inclination) to do the work themselves.
Fowler concluded his article by sharing his view of where the design payoff line is:
I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.
If that view is correct, almost all software systems would suffer from doing design trade-offs.