This reads more like a novel than a manifesto, but the gist is good. I think the name is misleading too, which doesn't help when you're trumpeting a manifesto.
When I read 'Code for Flexibility' I hear the antithesis of 'YAGNI', and think of large Java projects where every class implements interface and every interface has one and only one implementation. Yech.
The article makes some good points though, that could benefit from a restating. "This too, shall change" might be a good mantra for those writing software in almost all environments. "Don't get too attached" speaks more to me than "Code for Flexibility".
Change happens, we're evolving as a community to embrace that. Coding (up front) to anticipate change later, is a bad move, which while not the point of the article, is how I read the title and many of the headlines therein.
A very interesting read for the most part. I worry this kind of call to action will send a noob off in the wrong direction, even before they've actually learned the meaning and lessons behind what the author is hoping to prevent.
Personally, I think the biggest problem I find in other people's code smacks right up against the author's main point--it encapsulates one person's timestamped reasoning on a problem, and didn't keep in mind that that might either be wrong, or drastically change in the future.
I'd love to come across more 'flexible' code, but I'd be far happier to come across more code that is well-reasoned and thought out in a manner that makes inheriting said code to be more than a royal PITA.
When I read 'Code for Flexibility' I hear the antithesis of 'YAGNI', and think of large Java projects where every class implements interface and every interface has one and only one implementation. Yech.
The article makes some good points though, that could benefit from a restating. "This too, shall change" might be a good mantra for those writing software in almost all environments. "Don't get too attached" speaks more to me than "Code for Flexibility".
Change happens, we're evolving as a community to embrace that. Coding (up front) to anticipate change later, is a bad move, which while not the point of the article, is how I read the title and many of the headlines therein.