Maintability
Over time, many different people will work on the system (engineering and oper‐ ations, both maintaining current behavior and adapting the system to new use cases), and they should all be able to work on it productively.
Types of ongoing maintance:
fixing bugs
keeping its systems operational
investigating failures
adapting it to new platforms
modifying it for new use cases
repaying technical debt
adding new features
Minimise pain of doing maintaince
Make software have the following to avoid being "legacy" and dreaded to work on:
Operability: Making life easy for operations
Make it easy for operations teams to keep the system running smoothly.
Operation teams (ie tech ops/dbas/devops/release) responisbility (some of these might be the purview of the engineers):
• Monitoring the health of the system and quickly restoring service if it goes into a bad state • Tracking down the cause of problems, such as system failures or degraded performance • Keeping software and platforms up to date, including security patches • Keeping tabs on how different systems affect each other, so that a problematic change can be avoided before it causes damage • Anticipating future problems and solving them before they occur (e.g., capacity planning) • Establishing good practices and tools for deployment, configuration management, and more • Performing complex maintenance tasks, such as moving an application from one platform to another • Maintaining the security of the system as configuration changes are made • Defining processes that make operations predictable and help keep the production environment stable • Preserving the organization’s knowledge about the system, even as individual people come and go
Engineers help with these by providing the following:
• Providing visibility into the runtime behavior and internals of the system, with good monitoring • Providing good support for automation and integration with standard tools • Avoiding dependency on individual machines (allowing machines to be taken down for maintenance while the system as a whole continues running uninter‐ rupted) • Providing good documentation and an easy-to-understand operational model (“If I do X, Y will happen”) • Providing good default behavior, but also giving administrators the freedom to override defaults when needed • Self-healing where appropriate, but also giving administrators manual control over the system state when needed • Exhibiting predictable behavior, minimizing surprises
Simplicity: Managing complexity
Make it easy for new engineers to understand the system, by removing as much complexity as possible from the system.
Code can become complex as it grows. Which will slow down development and thus increasing time & cost of maintance. I.E. Big ball of Mud. This leads to budgets and plans to overrun
When making changes to complext systems, can lead to bugs. As the system is harder for developers to understand and reason about, hidden assumptions, unintended consequences, and unexpected interactions are more easily overlooked.
Symptons of complexity:
explosion of the state space
tight coupling of modules
tangled dependencies
inconsistent naming and terminology
hacks aimed at solving performance problems
special-casing to work around issues elsewhere
Simplicity does not mean reducing functionality.
Simpilicity should remove accidental complexity, complexity as accidental if it is not inherent in the problem that the software solves (as seen by the users) but arises only from the implementation.
Use of abstraction to hide details behind a facade, it can be reused. DRY.
Conflict between abstracting/drying out and readability.
Evolvability: Making change easy
Make it easy for engineers to make changes to the system in the future, adapting it for unanticipated use cases as requirements change. Also known as extensibility, modifiability, or plasticity.
System never remains constant, always in flux due to:
you learn new facts
previously unanticipated use cases emerge
business priorities change
users request new features
new platforms replace old platforms
legal or regulatory requirements change
growth of the system forces architectural changes
Out of date secruity protocols (ie certificates/passwords)
Use of Agile/XP, to help with constant change and gettting it out there. Easy to use in single project, but more difficult with whole systems of lots of applications
Last updated