Why is software architecture critical?
Why is software architecture so important and how can Lattix help?
Why is software architecture so important and how can Lattix help?
It is always hard to work on code that you did not originally build. It is even harder when the original developers who worked on the code are all gone, there is no documentation, and no one is exactly sure how it is implemented. Unfortunately, this is an all-too-common problem for businesses with legacy software applications. These legacy applications typically have been a driver of revenue and profits for the business for a long time, so they are vital. This means that as the business changes, these legacy applications need to be updated as well. But because of architectural drift and erosion, updating and fixing problems is hard and becoming harder all the time.
We write software to make our lives easier; to reduce the complexity and chaos. The need to reduce complexity is at the very center of software development. Unfortunately, we tend to mirror the complexity of the real world in our software and this leads to many problems. As Bruce Schneier in his essay A Plea for Simplicity: You can’t secure what you don’t understand said, “the worst enemy of software security is complexity.” In this blog post, we will talk about the importance of managing complexity and how to reduce complexity in software.
Fred Brooks, in his paper “No Silver Bullet: Essence of Accidents of Software Engineering”, explains there are two types of issues that introduce complexity, the essential and the accidental properties. Essential properties are the properties that a thing must have to be that thing. Accidental properties are the properties a thing happens to have, but they are not really necessary to make the thing what it is. Accidental properties could also be called incidental, discretionary, or optional properties. Brooks argues that difficulties from accidental properties have been addressed with higher-level languages, the introduction of IDEs, hardware enhancements, etc.
This leaves the problem of essential difficulties, and essential difficulties are harder to solve. You are now interfacing with the complex, chaotic real world where you must identify all the dependencies and edge cases for a problem. As software addresses larger and larger problems, interactions between entities become more complex, thus increasing the difficulty of creating new software solutions. The root of all essential difficulties is complexity.
Conceptual errors (specifications, design, and testing) are much more damaging than syntax errors. C.A.R Hoare, the inventor of the quicksort algorithm, stated in the talk The Emperor’s Old Clothes, “there are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are not obvious deficiencies.” Steve McConnell in Code Complete states that software’s primary technical imperative is to manage complexity. When software projects fail for technical reasons, one reason is often uncontrolled complexity (i.e. things are so complex that no one really knows what is going on). Edsger Dijkstra pointed out that no one’s skull can contain a whole program at once; we should try to organize our programs in such a way that we can safely focus on one part at a time.
Brooks paints a pessimistic picture of the future stating there is no “silver bullet” in either technology or management technique that promises even an order of magnitude improvement in productivity, reliability, or simplicity. While there is no silver bullet, there are things that can be done to reduce complexity.
When designs are inefficient and complicated they can be broken down into three categories:
As stated above, the most important technical goal is managing complexity. In terms of software architecture, complexity can be reduced by dividing a system into a series of subsystems. The goal is to break a complicated problem into simpler, easier to manage pieces. The less subsystems are dependent on each other the safer it is to focus on one area of complexity at a time. McConnell gives 14 recommendations on how to conquer complexity:
The importance of managing complexity can be seen when we start looking at other people’s source code. Depending on the complexity of the software, this can be a daunting task. As stated in Code for the Maintainer, “always code and comment in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.” Lattix Architect has helped hundreds of companies reduce the complexity of their source code by visualizing, optimizing, and controlling their software architecture.
CodeClinic, a provider of innovative solutions for software organizations in safety-critical embedded systems, received the Embedded World Award 2022 in the Safety & Security Category for Traci. This tracing solution is a traceability matrix used to identify gaps in the design and verification of requirements as required by standards such as ISO 26262, DO-178 B/C, IEC 62304, IEC 61508, and more. With Traci, functional safety teams can eliminate the manual error-prone process of conducting tracing analysis.
For some, architecture is all about decisions. Once the biggest and the most important decisions are made, architectural work is considered done. Sadly, the success of your project rarely hinges on those “big” decisions. It is the “small” decisions, the ones we often ignore, where a project’s success lies. The biggest decisions are static; once made they will rarely change. It is the small decisions, the ones we make every day, that will actually determine how easy it is to support new functionality and how productive the team can remain as software evolves.