> Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Funnily enough, "quick & dirt

> Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Funnily enough, "quick & dirty" code also often seems to ignore obvious easy solutions to any given problem and instead pursuits more cryptic/unmaintainable ones. That's the thing that bothers me the most when I'm encountering that sort of thing: It isn't just "a bit ugly" - more often than not it's hacked together using methods that merely almost work when there's a perfectly viable option that has been there since the 70s. And - on top of that - it usually even locks you in on those horrible decisions. Example: You have to configure a piece of software. The configuration is highly critical and must be maintainable and synchronizable between systems. There are tools that put their entire configuration in a database and sell it as a feature. To sum up: - You can't properly version said database - You can't diff said database - You can't grep said database - Reading the config takes ages if you can't use a different shoddy tool - Writing it manually is nigh on impossible - Errors get very obscure since you have to provide tables and IDs as references ...then why the hell aren't we just using text files for that? You could even insert the text verbatim into a table record and be better off.