"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 found it harder in large enterprises to anticipate the future with any certainty. One of the big problems was changing laws. Anytime the legislator is in session can cause serious changes in software. I remember a whole release totally shot because of changes in how reporting was done for the government.
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.
Chuck Moore is one of my heros, and has been since those '70s that he talks about.
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.
"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.