Now, let's look at the relationship between the source code and coding from a traditional angle. The word traditional here doesn't imply that this angle is old. Actually, by 2018, the idea that the source code is the design is 26 years old, since Reeves published his essay.

Traditionally, when we talk about software design and coding, we often compare this relationship with the one between design blueprints and the process by which engineers build houses, or with the one between car design and car manufacturing. With this assumption, we require up-front software design to guide us during the implementation of the application.

However, how many times have we found that we cannot follow a design to write the code because something is missing in the design or the requirement has been changed? And the design documents become obsolete the moment the code is written. You might think that this is because the effort put into code design isn't enough or the design isn't comprehensive enough to cover all of the requirements. Based on that, you demand to allocate more time for designing before writing the code. In reality, this doesn't always work.

Here is what is common in software application development. At the beginning of a project, a clean and elegant code design is crafted. However, with new features being added or changes being implemented, things start to go wrong. The code isn't following the design anymore, and in order to catch up with a tight schedule that is already behind, developers are forced to make compromises between getting it done right and getting it done fast. And then, the code becomes messy and turns into a pile of spaghetti code. You could see a lot of hacks and comments such as Refactor it later. This is a hack. Will come up with a better solution later in the code. And then, a simple change to a feature would cascade to other parts of the code, even those that are not related, and the cost of maintenance rises exponentially. This means that the existing code has become so fragile that developers start to write new code around it, which makes things worse, and eventually, they tell their managers that, without a redesign or a rewrite, no more changes can be implemented, because they might break other features that are already working, and it would take weeks, even months, to fix those potential issues.

Will a redesign solve this problem? It seems optimistic because now we have a much better idea of the features of the application. A redesign can embody those changes not included in the initial design. However, as said by Robert C. Martin in his book Agile Software Development: Principles, Patterns, and Practices, such redesigns rarely succeed. This is because the old system will continue to evolve and change, and the new design must catch up. There will always be changes that the designer can't foresee unless there is a crystal ball. Even when the new design reaches its first release, it might be just the beginning of another round of the cycle.