Maintaining What You Built
Launch day is exciting. The months after launch are where character is revealed. Software does not sit still once shipped — it decays, accumulates bugs, and faces an ever-changing world of updated dependencies, new security vulnerabilities, and shifting user needs. Maintenance is not a chore appended to real work. It is real work.
Why Software Decays Without Attention
Software rot — also called bit rot or software decay — is the phenomenon where software degrades in quality or stops functioning over time, without anyone changing the software itself. This happens for several reasons: Dependency drift: your application depends on libraries, frameworks, and runtime versions maintained by other people. When those dependencies release updates — especially security patches — your software falls behind. A library version that was safe in 2024 may have a known critical vulnerability by 2026. Operating system and platform changes: the infrastructure under your software evolves. A cloud provider updates its runtime. An API you call changes its authentication scheme. A browser drops support for a feature you rely on. Data growth: a database schema designed for a thousand records may perform poorly at a million. Performance issues that were invisible at launch become unavoidable at scale. Security threats: new attack techniques are discovered continuously. An application that had no known vulnerabilities at launch may become vulnerable as the security landscape changes around it. A concrete example: the popular Node.js library 'event-stream' was compromised in 2018 when its maintainer handed it to a malicious actor who added a cryptocurrency wallet stealer. Every application that depended on that library was affected — not because the application's own code changed, but because its dependency changed.
A dependency is any external code your application relies on to function — libraries, frameworks, runtime environments, external APIs. When you ship software, you ship every dependency's behavior alongside your own code. You are responsible for what your dependencies do to your users.
Maintenance work takes several forms: Bug fixes: correcting behavior that does not match specification. Bugs that go unfixed accumulate technical debt — future work made harder by present shortcuts. Security patching: updating dependencies and application code to address known vulnerabilities. Most professional teams treat security patches as non-negotiable, time-sensitive work. Performance optimization: identifying and fixing slowdowns as the application grows. Tools like database query analyzers and profilers surface where time is being spent. Feature maintenance: as the product evolves, older features may conflict with new ones, require updates to stay relevant, or need deprecation — the process of signaling that a feature will be removed and giving users time to adapt. Documentation updates: keeping internal documentation accurate so future maintainers (which may be you, six months from now) understand how the system works. The effort required for maintenance is often underestimated. A widely cited finding in software engineering is that maintenance typically consumes 60-80% of total software cost over a system's lifetime.
Complete each statement with the precise term from this lesson.
Maintenance in an AI-Assisted Codebase
AI-assisted development introduces a specific maintenance challenge: code you did not write line by line. When you use an AI tool to generate a function, that function becomes your code the moment you ship it. You own its behavior. When a bug is reported, 'the AI wrote it' is not a defense — and it is not practically useful, because the AI that generated it cannot patch it in production. This creates a discipline requirement: you must understand your codebase well enough to maintain it, even if AI helped you build it. Strategies: Read before you ship: before adding AI-generated code to production, read it carefully enough to explain what it does. You do not need to have written every line, but you must be able to reason about it. Test thoroughly: AI-generated code has the same failure modes as human-generated code — sometimes more, because it may confidently produce plausible-looking but subtly wrong logic. Automated tests give you a way to catch regressions during maintenance. Keep the codebase navigable: AI can generate large amounts of code quickly. Without discipline, the codebase becomes too large and tangled to maintain. Regularly refactor — reorganize the structure of code without changing its behavior — to keep it readable.
Many AI-assisted projects are built quickly, shipped, and then abandoned the moment the builder moves to the next exciting thing. Users who depend on that software — often students, small businesses, or under-resourced communities — are left with software that slowly stops working. Before you ship something people will depend on, honestly assess whether you can commit to maintaining it.
In 2018, the event-stream library was compromised after its maintainer handed it to a malicious actor. This incident illustrates which maintenance concept?
A student ships a web app in October. By January, three dependencies have released security patches, but the student has not updated them. The app has a known vulnerability. Who is responsible?
Maintenance Plan for a Real Project
- Step 1: Choose a software project — one you built, contributed to, or use regularly.
- Step 2: Identify its dependencies (libraries, APIs, platforms). List at least three.
- Step 3: For each dependency, write one sentence describing how a change or failure in that dependency would affect the software and its users.
- Step 4: Draft a six-month maintenance plan: what would you check, and how often? Include: dependency updates, security review, performance check, documentation review.
- Step 5: Estimate the time cost of your plan per month. Is this a project you could actually maintain? What conditions would make you hand it off or deprecate it?