This is usually the status quo that I initially walk into.   The first, and perhaps the most difficult, step is to persuade management to treat a software project exactly as they would treat “the building of an automatic machine.”

Computer software is, in fact, an automaton.   Acting only and completely on the yes/no instructions of which it consists, the machine is expected to correctly perform (or, correctly and meaningfully decline to perform) a real-world business process for a business consisting of humans.   If the software code-base here really is as you describe it to be, the root cause of the problem lies in [the lack of] software project management.   The code was “untested,” yet it was released and is in service.   There is no such thing as “technical debt,” but the business cost of software failure – or even, inadequacy – is more than “measured in cash.”   If the organization does not fundamentally change its approach to software building, then any “rewrite everything in” successor will merely suffer the same fate.

Usually, the root cause of the problems do not lie in the day-to-day activities of the code writers.   The problem is upstream of this, in the business itself.   But this is partly a social consequence of the very attitude that Joel’s article (Joel knows his audience ...) speaks to:   that the software developer’s job is to take “business requirements” and to “write code” for it, and that those requirements ... a wish-list, really ... can, in fact, be changed arbitrarily without harm or consequence.   Strangely, no one thinks that way when designing buildings or physical machinery.   Yet, computer software is a machine with more degrees-of-freedom and loose-motion than any physical artifice could ever have.

If you find yourself speaking to “CVS vs. git,” then this is probably a symptom of “lack of version control and/or of release discipline.”   If you are even discussing the importance of code-review and testing, it’s a symptom that these things are not burned-into the organizations process culture.   Basically, that there is no process culture.   A dire situation like this one must be simultaneously addressed at multiple levels:   (Okay, a taste of what I do for a living ... tough love.)

1. Triage:   Stop the bleeding.   Get control of business blood-pressure, even if you must amputate a limb of the existing app/web-site (temporarily ... or not ...) in order to stabilize what’s left.   Stop all “future development,” because it will not matter in the end if a corpse [failed business ...] has yet-another half-grown arm in its [defunct ...] web site.
2. Eliminate “self-serving software excuses for” actual project management:   Out with the Scrum, the Agile, the euphemisms like “technical debt.”   “Everyone, please sit down.”   No amount of quibbling about exactly how a group of software-writers spends their work day will, in the end, make the slightest bit of difference, as long as the teams are being asked to perform a series of tasks that are not rigorously defined before being presented to them, having first gone through an analysis & planning stage which translates business requirements into modifications to a now-moving machine otherwise known as “the application.”   Yellow sticky-notes don’t solve anything, and focusing on such things is merely indicative of the root problem.   Carpenters and masons and electricians do not have discretion.
3. Get to “Big-D Done,” then “Move From Done to Done”:  
   1 = It Works, completely, perfectly, and in all cases.   0 = It Doesn’t.
   “Yeah, it sucks to be binary,” but a digital computer is.   The software machine consists of millions of freely-interacting moving parts, all of which are “either Yes or No.”   “Either Done or Not-Done.”   “Proved to be Correct, and to stay Correct in all cases.   Or, not.”   You can’t talk about “technical debt” because functionality is either in the product or it’s not, and the cost of any change is the same in terms of its risk to product stability.   You didn’t “incur a debt to be paid-back later.”   You didn’t do it.   And even if you did, it’s most likely not Done.™

I could continue, but I’d have to charge you.   ;-)   Basically, software development fails consistently because the work actually consists of building an automated, moving, piece of machinery but nobody approaches the task in that way.   Programmers focus on how they arrange their tool-boxes, what they wear to work, and where they stand at 10:00.   Business owners stand at a distance, staring at metrics but without knowledge of the process.   Incomplete requirements are handed down because those that supply them don’t know what is required.   Changes are handed down ... but without a change-order process ... because neither party understands the cost and risk of “any change at all.”   And the software machine chugs along, full of broken parts, incomplete behavior, and badly-dented covers (emitting foul smoke) which haven’t been opened in years.

The business failure, though, is not a failure of computer technology, nor of the language(s) that are used.   The business failure is ... well ... a business process failure.   But it is also a failure to recognize that the singular ruling constraint of this kind of project – altogether different from any other type of project – is the software machine.   At the end of the day, no one is there but the machine and its user.   The programmers, the managers, the testers, no one has any direct influence on what the machine does.   No other type of project that has ever been “managed” has that characteristic, and “that characteristic” trumps all other concerns.   It is the Nature of The Beast.

(You can find it on Kindle (Amazon) now; soon to be on Apple platforms too:   Managing the Mechanism, by Vincent P. North.)