2 ms·

Maybe this works in the short term, but if your policy is always to "deliver something, anything", you'll find it harder and harder to deliver anything, and mor

by panic 9y ago

Maybe this works in the short term, but if your policy is always to "deliver something, anything", you'll find it harder and harder to deliver anything, and more and more bugs appearing when you do. You need to understand the meaning of the code to successfully change it. Code written following this "deliver anything" policy will tend to have unclear, inconsistent, or flat-out nonexistent meaning. Further changes written like this will keep eroding the meaning until you're left with a program that can only be understood in terms of what happens when you run it. You can never be confident making changes to a program like this, because you don't have a coherent understanding of how each change will affect the system as a whole: all you know is how it will change the behavior when the system is run in a particular way. You don't have to be a perfectionist to understand this!

btschaegg 9y ago
> 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.

by panic 9y ago

btschaegg 9y ago

> 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.