Code-and-Fix Development
McConnell's original definition from his Professional Software Development (2003) book, p. 50.
..."code-and-fix development" jumping straight into coding without planning or designing the software first. Sometimes teams do this because the team's software developers are anxious to begin coding. Sometimes they do it because managers or customers are eager to see tangible signs of progress. Code-and-fix development is universally ineffective on all but the tiniest projects; 1
The more involved descriptions would sound like this:
Code-and-Fix Development is an informal, unstructured approach to software development where developers immediately start writing code without prior planning, design, or formal processes. The cycle typically involves:
- Writing code without upfront requirements or design.
- Fixing issues as they arise during testing or use.
- Repeating the process until the software works "well enough."
Characteristics
- No formal requirements analysis or design phase.
- Minimal documentation.
- Reactive bug-fixing rather than proactive problem prevention 2.
- Ad-hoc changes without systematic testing or long-term maintenance considerations.
When is it Used?
- Small, simple, or throwaway projects.
- Prototyping or proof-of-concept work.
- Situations with extreme time pressure (though this often backfires).
Drawbacks
- Unmaintainable code: Lack of design leads to spaghetti code.
- High technical debt: Quick fixes accumulate, making future changes harder.
- Unpredictable timelines: Bugs and rework cause delays.
- Poor scalability: Not suitable for complex or long-term projects.
Footnotes
-
I did not find an original definition in the internet, so I put it here to refer conveniently from my other materials. ↩
-
"proactive problem prevention" may look to someone like "over-engineering", but in "code-and-fix" there is neither "over", nor "engineering". Clearly engineered requirements are the baseline to measure for what is "over", non-essential engineering. No clear deterministic requirements - no point talking about over-engineering as no comparison base exists. ↩