Getting the architecture of an enterprise software system right can be tough. There are a lot of variables, a myriad of options, and many ways to get it wrong. Often, development teams don’t realize that the architecture is weak until serious problems appear in production. By then, there’s extreme reluctance to admit that the architecture needs to change.
There are no simple, obvious signs that a software system has been poorly designed. Every major software implementation demands compromise. For example, a team under pressure might decide to focus on heavily used parts of the architecture and cut corners on the little used areas. I wouldn’t recommend that approach but it happens — probably more often than any of us want to admit.
With that in mind, here are some early warning signs that your software architecture may not be as optimal as you’d like it to be.
- The software is difficult to change. Changing one area of the code requires changes to one or more other areas — a cascade effect. You never know how many changes will be needed to fix a flaw or introduce a new feature.
- The software is fragile. Every time you fix a defect, something else — seemingly unrelated — breaks. This requires exhaustive testing of the entire system for every change.
- There is little, if any, reuse. Developers prefer to write new code from scratch rather than take advantage of something similar that already exists in the system.
- There are excessive checkouts/checkins in one area of the code. If the team is revisiting a section of the code on a regular basis to resolve new problems, that section is poorly designed or written.
- Exceptions are not handled gracefully and they are not logged. Software crashes, cryptic system error messages, and unexpected software behaviors indicate poor engineering practices.
- The knowledge base is shallow. This occurs when there’s little system documentation and every architecture question needs research. The team not only lacks system knowledge. They are also likely dealing with an overly complex architecture.
- There are many big software classes (modules). This is a classic sign of poor architecture. It’s often faster to simply write one giant module than several smaller ones. Unfortunately, the giant module is harder to test and maintain.
- The system control logic is overly centralized. With the exception of some types of embedded systems, software should exhibit distributed control. Having too much intelligence in a single module causes bottlenecks and contention issues.
- The system control logic is overly decentralized. Spreading logic out among too many modules can also be a maintenance nightmare. If simple logic changes affect many modules, the team may be getting carried away by a passion for distributed logic.
- Similar functions are implemented inconsistently. If developers implement code modules any way they like without considering how existing modules operate, the code will become inconsistent, confusing and error prone.
I hope this list gives you some food for thought. Minor issues can be handled by refactoring. Major ones will require significant rework. When you identify these kinds of issues, allocate time in your next release cycle to address them. They will only get worse over time.