Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.
It seems that many programmers believe that writing 10x the amount of code to solve a "simple" problem in a complex, yet "general" way is somehow a win.
I wonder if that has to do with having a better grasp of the "complex" problem, so you develop a belief that you "understand" the problem, and can therefore "solve" it?
We know from study after study that 10x the code generally means 10x the bugs -- that bugs scale linearly with text on the page.
And yet we still don't want to solve the problem at hand in the simplest possible way. We don't want to specialize our code. We don't want to write 1/10 the code that just does the present job, and does it well.
I'm as guilty as the next programmer, but I wish I understood the impulse better...
Simplifying problems is hard work - it means making firm decisions about your needs and laying bare how much of your work is truly original, vs. being regurgitated effort done thousands of times by others.
Writing a very complex solution appeals because it defers that work until later: "when I decide what I want, I'll just configure it that way." (And then you never decide.) Bonus points for "it will be the fastest/most comprehensive/most modular solution around." You reassure yourself, with one of these fallacious ideas, that "other people will use this for many years."
This is an issue that goes straight to the programmer's ego and purpose as a craftsman - who are they writing code for, what problems they are solving, what is the thing they are going to tout on their resume. They aren't going to be confident or arrogant enough to railroad all projects into minimal, ground-up Forth-idiomatic projects. Most of the perceived brass rings revolve around short-term ideas like a buzzword technology or a new platform or some other obviously overcomplicated and unnecessary thing.
I have tremendous respect for Chuck and have definitely aimed to emulate him more and more, little by little, though I am not a Forth coder and cannot claim to have neared the style he advertises. My most reusable bits of code tell a similar tale, though: Algorithm and data structure implementations. Parsers and compilers. Formats and protocols. In between those, lots of architecture that I thought was a good idea. Most of it unnecessary.
Side note: Format and protocol support tends to introduce a tremendous amount of complexity. The sign of a good format is in how much it manages to limit this "complexiplosion" while still giving users the features they need. One of the things holding me back is my desire to stick to existing formats.
It seems that many programmers believe that writing 10x the amount of code to solve a "simple" problem in a complex, yet "general" way is somehow a win.
I wonder if that has to do with having a better grasp of the "complex" problem, so you develop a belief that you "understand" the problem, and can therefore "solve" it?
We know from study after study that 10x the code generally means 10x the bugs -- that bugs scale linearly with text on the page.
And yet we still don't want to solve the problem at hand in the simplest possible way. We don't want to specialize our code. We don't want to write 1/10 the code that just does the present job, and does it well.
I'm as guilty as the next programmer, but I wish I understood the impulse better...