3 ms·

It's easier to make Beautiful readable, testable, maintainable code that fails to meet the business need into working code than it is to turn ugly, unreadable,

by pdpi 12y ago

It's easier to make Beautiful readable, testable, maintainable code that fails to meet the business need into working code than it is to turn ugly, unreadable, untested, unmaintainable (but working) code to a state where it's not a tragedy waiting to happen. Edit, in a less snarky tone: If beautiful, readable, testable maintainable code is buggy, I'd bet money on the project being structurally sound, but the developer having failed to understand something about the business requirements. It'll likely take a little while to get familiarised with the structure of the code, and then some more time to identify (and fix) the parts of the business logic that are not working as expected. Ugly, unreadable, untested, unmaintainable code that "works" usually doesn't actually work, not really anyhow. It works fine for the cases that make the bulk of day-to-day work, but is almost certainly going to fail horribly when you hit an unusual corner case, and fixing that corner case is going to be a pain, because the lack of structure and testing is going to make it really easy to accidentally break something, and really hard to identify that this has happened (and why).

federico3 12y ago
You are conflating "ugly/unreadable" with "untested" and with "unreliable". There's plenty of horrible but reliable code out there, and vice versa.
- pdpi 12y ago
  I'm conflating them because, in my experience, they're not independent. There are, of course, plenty of exceptions, but those characteristics tend to go hand-in-hand. It's also often the case that what superficially looks like "ugly reliable code" actually means code that was, at one point, very simple and tidy but has been battle-hardened by years of maintenance. It's ugly because code that implements a lot of complexity tends to look scary as hell. Finally, it's ultimately a truism: truly unreadable code is also code that's hard to modify, and very few systems will go through their lifetime without changes. Even if it works fine today, it'll not meet business requirements tomorrow, and its unmaintainability is a liability.

by pdpi 12y ago

federico3 12y ago

You are conflating "ugly/unreadable" with "untested" and with "unreliable". There's plenty of horrible but reliable code out there, and vice versa.

pdpi 12y ago
I'm conflating them because, in my experience, they're not independent. There are, of course, plenty of exceptions, but those characteristics tend to go hand-in-hand. It's also often the case that what superficially looks like "ugly reliable code" actually means code that was, at one point, very simple and tidy but has been battle-hardened by years of maintenance. It's ugly because code that implements a lot of complexity tends to look scary as hell. Finally, it's ultimately a truism: truly unreadable code is also code that's hard to modify, and very few systems will go through their lifetime without changes. Even if it works fine today, it'll not meet business requirements tomorrow, and its unmaintainability is a liability.