1. SOFTWARE IS DEVELOPED, NOT MANUFACTURED A car has a design phase and then a manufacturing phase, and manufacturing dominates the cost. Software has ONLY the design phase — copying is free. → CONSEQUENCE: quality cannot be inspected at the end of an assembly line. It must be built in during design, because there is no other phase in which to add it. → CONSEQUENCE: cost estimation means estimating INTELLECTUAL effort, which is far less predictable than estimating material and machine time. 2. SOFTWARE DOES NOT WEAR OUT Hardware follows the BATHTUB CURVE: high initial failures (manufacturing defects), a long flat period, then rising failures from wear. Software has no physical wear, so the ideal curve would simply fall and stay flat. The ACTUAL curve rises again — not from wear but from CHANGE: failure ┤╲ ╱ ← rises from CHANGE rate ┤ ╲ actual curve ╱ ┤ ╲___ ______╱ ┤ ╲╱╲__╱ ← each change introduces defects ┤ ideal (flat forever) └──────────────────────────► time Every fix or enhancement risks introducing new defects, and the code becomes harder to change as it accretes. That decay is called SOFTWARE ENTROPY or "bit rot" — a misleading name, since nothing rots; the code is byte-identical. What changed is its ENVIRONMENT and its accumulated modifications. 3. SOFTWARE IS COMPLEX Complexity grows faster than size. A program of n interacting parts has up to n(n−1)/2 possible interactions: 10 modules → 45 possible interactions 50 modules → 1,225 100 modules → 4,950 This is why MODULARITY and INFORMATION HIDING matter: they are the only tools that stop the interaction count from exploding. 4. SOFTWARE IS INVISIBLE / INTANGIBLE You cannot look at software and see its structure the way you can look at a bridge. Progress is therefore hard to measure — "90% done" is the most dishonest phrase in the industry, and it is dishonest without anyone intending to lie. 5. MOST SOFTWARE IS CUSTOM-BUILT, NOT ASSEMBLED Other engineering disciplines assemble standardised components. Software reuse is real but still limited, which is what COMPONENT-BASED SOFTWARE ENGINEERING (ACtE0802 topic 14) tries to change. 6. SOFTWARE IS EASY TO CHANGE — AND THAT IS THE PROBLEM Changing a bridge requires cranes; changing software requires a text editor. Because change is cheap to ATTEMPT, it is attempted constantly, and each attempt risks correctness. Physical constraints impose discipline that software lacks.

SOFTWARE APPLICATION DOMAINS: SYSTEM software compilers, OS, drivers, utilities APPLICATION software business and standalone programs ENGINEERING/SCIENTIFIC simulation, CAD, numerical analysis EMBEDDED software resides in ROM, controls hardware PRODUCT-LINE software a family of related products WEB/MOBILE apps network-delivered, frequently updated AI software non-algorithmic solutions — expert systems, pattern recognition, neural networks LEGACY SOFTWARE — the software that is old, essential and frightening to touch. · it embodies business rules that exist nowhere else, often not in any document · the original authors have left · it may have no tests → the rational choice is usually to keep and adapt it, not rewrite it, because a rewrite discards decades of accumulated bug fixes and undocumented requirements. That is counter-intuitive and it is why "let us just rewrite it" projects fail so often. THE FOUR OPTIONS for legacy code: 1. SCRAP it entirely (only if the business process has changed) 2. CONTINUE maintaining it as-is 3. REENGINEER it to improve maintainability, keeping the functionality 4. REPLACE it (highest risk) SOFTWARE MYTHS worth being able to refute — they appear in exams as "comment on the following statement": MANAGEMENT MYTHS "A book of standards is enough." → having standards and USING them are different things. "Adding programmers to a late project speeds it up." → BROOKS' LAW: it makes it later. New people need training (taking time from productive staff) and add communication paths — n people have n(n−1)/2 channels. "Outsourcing solves the problem." → a company that cannot manage software internally cannot manage a vendor. CUSTOMER MYTHS "A general statement of objectives is enough to start." → ambiguous requirements are the leading cause of project failure. "Requirements change is easy to accommodate." → cost of change rises steeply with phase (below). PRACTITIONER MYTHS "Once the program works, we are done." → 60–80% of total lifetime effort is spent AFTER first delivery. "The only deliverable is working code." → documentation and tests are what make the code changeable. "Quality assurance wastes time." → see the cost-of-change curve.

THE COST OF CHANGE — the single most important quantitative idea in software engineering. The relative cost of fixing a defect, by the phase in which it is FOUND (Boehm's classic figures, still broadly reproduced): phase found relative cost ──────────────────────────────── requirements 1× design 3–6× coding 10× unit/integration test 15× system test 30–70× AFTER RELEASE 40–1000× cost ┤ ╱ 100× ┤ ╱ ┤ ____╱ ┤ ___╱ ┤ ____╱ ┤ 1× ╱ └──────────────────────────────────────► req design code test system release WORKED IMPLICATION: a defect that costs ₹1,000 to fix during requirements costs ₹100,000 after release — a 100× multiplier. If a requirements review costing ₹50,000 catches even ONE such defect, it has paid for itself twice over. That arithmetic is the entire justification for reviews, inspections, and writing requirements down before coding. It is not process for its own sake; it is a 100:1 return. WHY THE CURVE IS SO STEEP: a requirements error found at requirements time means editing a sentence. The same error found after release means diagnosing it in production, fixing the code, re-testing everything it touches, re-releasing, possibly migrating data, and dealing with whatever damage the wrong behaviour already caused.