Blog.CBojar.net

You're sitting there staring at the (pretty good if you say so yourself) code you just wrote. It solves a pretty tricky problem in a pretty elegant way. But something is worrying you: this code might need to change. You're not sure when and you're not sure how, but you just get this feeling tingling in the back of your neck that this code is going to have to change, and probably sooner rather than later. Somehow sensing your hesitation from across the room, that guy comes over. Yo, bro, looks like you got a problem. Just remember, bro, YAGNI! You ain't gonna need all that! You've heard it all before from that guy . You've even followed his advice a couple of times. Once, yeah, he was right, but that other time... oh, that other time. So much extra work that you just know you could have avoided, somehow. Maybe I exaggerate a bit, but we've all seen or heard of or (shudder) worked with someone who strictly follows the One True YAGNI. They never add any co...

In code, as in life, things are always changing, whether we want them to or not. (Focusing on the code part,) Operating systems, libraries, protocols, languages, standards, and best practices are changing on the regular underneath every bit of code we write. While many of these systems work hard to change in "backwards-compatible" ways, sometimes there are changes that break things. As software developers, our job is to write our code that is robust to change, so that it still works well when the future arrives. But sometimes there are those among us who suffer from #FOChaCo: the fear of changing code. Despite the inevitability of the future, they fight tooth and nail to keep things exactly as they were. They might insist that we cannot support anything later than version X of our platform, or that we should not update any libraries unless there is a dire need to do so. These developers are well-intentioned. They may have been bit in the past by a library update. They might...