Stakeholders: Key to a successful Software Architecture 3 - Software Developers

In the previous article of this series, we have explored the software owner's viewpoint for a successful architecture. Here we will take up developers' expectations from a well designed architecture.

While developing large software systems, everyone gets ample opportunity to work on existing modules or software. Complaints of poorly written, inflexible and fragile systems are very common. Let’s see what can be done to make developers relatively happy in their job:

1. Modularity: Greatest nightmare for a developer is a broken system due to seemingly unrelated source code change. Modularized architecture not only prevents it but allows development and testing of different modules in isolation and parallel. Use of principles like SRP, OCP and Liskov Substitution help creating well defined and separated modules.
2. Plausible: A far-fetched architecture usually incorporates too many unseen possibilities and becomes unnecessarily generic. Addition of any functionality in such software, becomes unusually costly and demotivating. Often those generalizations never meet compelling problems in their lifetime to justify them. History suggests that the business scenarios change so unpredictably that flexible and adaptable architecture is far better than the large one incorporating future features.    
3. Interfaced communication: When every component of a software system starts communicating with every other module, the whole system becomes one monolithic structure. It leads to frequent break ups and unreliability. Only solution is to control communication among various components through well designed interfaces or APIs. Principle of Interface Segregation is a must while designing these APIs.
4. Diagnostics: While developing a large software, programmers spend a good amount of time on debugging. System should be able to present relevant debugging information in a manner that should be most useful to the programmer. While good IDEs are very essential for quick and quality debugging, well interfaced and loosely coupled modules allow problem isolation and service mock-ups. Therefore, effective diagnostic concerns are essential to a sophisticated architecture.
5. Replication of source or resources: If, in a system any information is stored at multiple places or a source code is repeated in multiple modules, then sooner or later copies will go out of sync hampering reliability seriously. Architects are supposed to look for “Don’t repeat yourself” violation continuously while architecture is evolving.
6. Easy to understand: Simple and easy to understand architecture allows developers to follow its conventions and protocols. Such systems not only preserve their shape for a longer time but also evolve naturally. They even require less documentation. Also, developers feel confident while making corrective decisions during its evolution.
7. Abstraction: An architecture is an abstraction of different components in a software system. This abstraction should be as generic as possible. In other words, it should not depend on any specific framework or product. It allows developers to choose the most suitable implementation of a given abstraction.

In the next article of this series we will discuss the say of third party vendors and quality engineers towards a good software design.

Graphics credit