23 ms·

"If you don't have time to get it right the first time, how on earth will you have time to do it again?" I like that quote, but to be honeste. Some times you h

"If you don't have time to get it right the first time, how on earth will you have time to do it again?" I like that quote, but to be honeste. Some times you have to get it out of the door, and time is of the essence. And you can go back and fix it. That is okay, as long as you understand that shortcutting now, will cost time tomorrow (i.e. technical debt).

btschaegg 10y ago
Yeah, the problem appears if your superiors don't understand that. It'll be a "quick fix", when you want to clean it up after the crunch the comments will be "nah, we don't have time for that right now" (non-coders never seem to understand that messy code is a liability - thus cleaning up code seems like a waste of time). And a couple of months later, it comes back biting you in the behinds. At which point, someone will tell you or some other unfortunate colleague to "just fix it quickly". In such an environment "quick and dirty" only works if it is kept locally, i.e. the author is the only one that uses the code. Hence Uncle Bob's insistence that a good developer must say "NO!" from time to time[1]. [1]: https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no https://sites.google.com/site/unclebobconsultingllc/blogs-by...
- lloeki 10y ago
  > non-coders never seem to understand that messy code is a liability If J. Random Folk were to go to the nearby mechanic to try and fix his car, he'd be very upset at him for stitching things with duct tape and calling it a day. Yet this is mostly the default expectation from "non-coders", who are all up in arms because you're being a "perfectionist" when you're just being a responsible professional. Sad.
- taurath 10y ago
  Big difference between intentional and unintentional technical debt. If you as the programmer are taking on intentional technical debt but the people making resource decisions don't know about it, it is in fact unintentional technical debt.

btschaegg 10y ago

Yeah, the problem appears if your superiors don't understand that. It'll be a "quick fix", when you want to clean it up after the crunch the comments will be "nah, we don't have time for that right now" (non-coders never seem to understand that messy code is a liability - thus cleaning up code seems like a waste of time). And a couple of months later, it comes back biting you in the behinds. At which point, someone will tell you or some other unfortunate colleague to "just fix it quickly". In such an environment "quick and dirty" only works if it is kept locally, i.e. the author is the only one that uses the code. Hence Uncle Bob's insistence that a good developer must say "NO!" from time to time[1]. [1]: https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no https://sites.google.com/site/unclebobconsultingllc/blogs-by...

lloeki 10y ago
> non-coders never seem to understand that messy code is a liability If J. Random Folk were to go to the nearby mechanic to try and fix his car, he'd be very upset at him for stitching things with duct tape and calling it a day. Yet this is mostly the default expectation from "non-coders", who are all up in arms because you're being a "perfectionist" when you're just being a responsible professional. Sad.
taurath 10y ago
Big difference between intentional and unintentional technical debt. If you as the programmer are taking on intentional technical debt but the people making resource decisions don't know about it, it is in fact unintentional technical debt.