During my insignificant life, up to now, I’ve seen many times people writing bad, or really bad, or really really bad code with the excuse of a tight timing or a dead-or-alive deadline to deal with.
It’s the principle that is wrong. If you are one of those, let me tell you why you are a failure yourself. You’re doing it wrong and you probably did since the beginning of your <latest coding adventure>.
At some point in the process, you started trading fast, easy designing and coding in change of less hassles (typical words: “who cares”, “we’re going to use <put-your-favourite-SQL-engine-here or other query language> anyway”, “this code has to do this-and-that, period”, “i’m not planning other features”). The funny part is that you did that with the Devil: you just sold (a part of) your soul to him (see “Bedazzled”, 2000, it’s a funny movie). And we all know that the Devil someday will knock back at your door.
This is not good for your health either. And it’s what the so called “Agile programming” tries to avoid you. Agile programming, besides its scientific definition and explanation has the “side-effect” of “forcing” (see the quoting) you to write good code, with a good level of abstraction. Given that it warmly welcomes people wanting to throw code away for a rewrite (refactoring), keeping your architecture fresh over time.
Thanks to my dedication in trying to keep the whole Entropy (the package manager I wrote for Sabayon) architecture as much clean as possible (it’s still a “one-man-army” project), today I can happily break the underlying SQLite3 db schema without worrying of possible higher level consequences and, more important than anything else: keeping the holy backward compatibility. Also thanks to Agile programming (which is something nobody can realize by watching a plain git log).