1.3 Characteristics And Types Of Software
Software behaves differently from many physical products. You can copy it cheaply, change it quickly, and connect it to everything. Those strengths create engineering problems too.
Important characteristics include complexity, invisibility, changeability, conformity, and discontinuity. A tiny code change can trigger a large behavior change because software is full of exact conditions and hidden interactions.
Software is shaped by context
The same feature means different engineering work in different products.
| Context | What often matters most |
|---|---|
| SaaS product | Fast learning, safe rollout, data compatibility, observability |
| Embedded system | Resource limits, hardware interaction, field updates, reliability |
| Regulated system | Traceability, verification evidence, change control, auditability |
| Internal tool | Workflow fit, permissions, maintainability, low support burden |
| Open source library | API stability, documentation, compatibility, community trust |
The mistake is assuming your favorite engineering style is universally correct. A prototype mindset can save an uncertain product idea and damage a safety-critical workflow. Heavy documentation can protect a regulated release and suffocate a throwaway experiment.
Quality attributes compete
Quality is not one thing. A real system must trade off:
- Reliability: does it keep working correctly?
- Maintainability: can future people change it safely?
- Security: does it resist abuse and protect data?
- Usability: can intended users succeed without fighting the product?
- Performance: does it respond within useful limits?
- Scalability: can it grow without redesigning everything?
- Availability: can users reach it when they need it?
- Recoverability: can the team restore service after failure?
A practical rule
When entering a new project, ask:
- What type of software is this?
- Who is harmed when it fails?
- How quickly can we detect a bad change?
- How quickly can we reverse a bad change?
- Which quality attribute would users notice first?
Those questions usually produce better engineering choices than starting with a framework, architecture style, or process label.