The Relationship of Rhetoric and Technical Design
When I was in college, my first year in the school of computer science had me in multiple courses directed towards writing code and completing lab exercises. I would classify this first class as a “coding class”.
My first year studying computer science was all about writing code, countless lines written for common beginner projects, and an intense focus on syntax and the core features of C as a programming language. Lab project after lab project, I wrote more code in that year than I had at any time leading up to it. The first year’s curriculum was just a year of coding. It wasn’t until my second year in the school of computer science that I took my first true course in software engineering. The distinction wasn’t about the course title – I think of that second-year class as my first real computer science course because it introduced a core concept of software engineering: solution design.
Rhetoric: The Hidden Foundation of Software Design
Though I did not realize it at the time, I had already been exposed to the principles of software engineering earlier in my education. These principles were introduced through a course on the rhetorical analysis of literature. The class revealed that communication relies on rhetorical patterns, the structures that carry a message toward understanding and purpose. Understanding why a written work is effective requires understanding the rhetorical patterns used in its construction. Works that were effective in their goal incorporated rhetorical techniques and structural patterns that were complementary and cohesive with respect to the goal of the piece. The unsuccessful works jumped between techniques and used patterns that had the same goal but were incompatible with one another. Consequently, they read as dissonant and ineffectual – sometimes they were just confusing. Successful rhetoric is successful because it was intentional. The importance of each of the work’s structural elements was apparent due to the patterns present when the work was planned. In turn, these features resulted in clear, effective literature.
Why Understanding Design Principles Enables Long-Term Success
Technical fields, at a high level, have a common goal of producing reliable and maintainable solutions. Successful projects from an engineer or IT professional parallel effective rhetoric. The production of an effective and nontrivial solution requires that the solution first go through a design phase. Design prioritizes the use of patterns that are cohesive in concept and purpose, which is the foundational step in creating a solution that is understandable.
Maintainability follows understanding; when personnel understand the design and how each component of the implementation relates to the design, they are empowered to perform upkeep that follows the patterns and principles of the design. Implied in all of this is the assumption that design documentation is readily available and kept updated so teams may form an understanding to guide their actions. Then, so long as the respect for the design is upheld, the solution can continually be maintained via the understanding brought forth due to intelligent design.
How Purposeful Design Prevents System Decay
Given an architecture outlined with clear design principles and cohesive design patterns, a solution can see maintainers come and go throughout the solution’s life and still fulfill its purpose. Conversely, it is the experience of many engineers tasked with maintaining a legacy solution that lacks documentation or a clear design to puzzle over, and potentially break, the solution. Effective solutions are effective because they were designed intentionally. Solutions are effective when the patterns present in the design communicate the pursuit of purpose. The design is the vehicle by which one understands how each element’s role achieves the solution’s purpose. When elements of the solution are implemented in conjunction with a design that is cohesive in concept and purpose, solutions can be relied upon throughout their lifetime of maintenance and the iterations of improvements to come.
Author: Philip Merry, CX – Software Engineer at SIOS Technology Corp.
