Chuck Moore on the Lost Art of Keeping It Simple
simple-talk.com
simple-talk.com
"Second, it’s irresistible to anticipate the future and expect the problem to grow in a certain direction. Thus code is added to facilitate future changes, which rarely occur. This is a good strategy, but can be put off until the future arrives."
Should we even know what the future is likely to hold? I'm in a big corporate - perhaps that skews things where I am, but we have a relatively clear roadmap for the next couple of months at least, and I am loath to ignore that, although I am mindful of the problem mentioned as well: I don't try to solve future problems before we get there.
Should I cease specifically allowing for them?
NB the organisation I am working in allows approximately 2% of developers' time for refactoring.
I often wonder what would happen if some fundamental change occurred that affected a basic assumption of a lot of software. The nastiest example would be civil unions allowing more than 2 partners. That would probably destroy a goodly chunk of release schedules in most enterprises.
I think the simpler you keep it will help when you really need to change something. Programming in Forth really let you feel that.
Try as I might, I have had a hellofatime using Forth (and now Factor) to get nontrivial things done. But I keep trying, because I find the philosophy so compelling. And I figure I'll learn something.
He has always considered Forth to be a 'personal leverage' tool rather than a programming system suited to a team. Similar in this regard to Lisp and J I suppose. The fact that he has never hired a programmer (!) reinforces this notion.
I wish him luck with his chips....
Bob