4 ms·
We've been refactoring and decoupling code for decades in imperative coding styles. I think one of the problems we have as a community of programmers is the co
by mikekchar 10y ago
We've been refactoring and decoupling code for decades in imperative coding styles. I think one of the problems we have as a community of programmers is the concept that it must end up in a ball of mud. Almost all of our extant systems are developed in imperative style. The system I work on today is many orders of magnitude larger than the systems I first learned on and yet it is dramatically easier to write useful code. That's because over time, we have extracted and polished functionality into useful and unambiguous pieces.
Back when I was a young programmer it was often said, "If you don't have time to get it right the first time, how on earth will you have time to do it again?". To me, this concept is why we get into the ball of mud. It will happen to you no matter what style of programming you choose, because you can't get it "right" the first time. You don't know what "right" is. Because we resist the rework/refactoring, we build balls of mud. We even blame it on the people before us "who got it wrong" (which is easy to do because average attrition is about 2 years and they've likely left the company).
I like functional style as much as the next programmer (well, probably more than most in fact), but FP isn't going to save you in this instance. The only way to maintain high levels of productivity in projects is ruthless rework in the face of changing requirements.
- hvidgaard 10y ago"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 agoYeah, 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 agoBig 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.