Fool Me Once...
Here's an excerpt from Robert Martin's "Agile Software Development" that resonated with me:
There is an old saying: "Fool me once, shame on you. Fool me twice, shame on me." This is a powerful attitude in software design. To keep from loading our software with Needless Complexity, we may permit ourselves to be fooled once. This means we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind. In short, we take the first bullet, and then we make sure we are protected from any more bullets coming from that gun.
Basically, this goes to the "Do The Simplest Thing Possible" principle of XP. I've heard and read this mantra several times. Now, I like the sentiment, but it's hard to turn off that voice in your head that's going: "Put that hook in because you might need to do X, Y, or Z." It's very tempting to put the hooks in because it's been drilled in your head. So, I have been trying my damnest to do "the simplest possible thing". This has even meant that I have tried programming without accessors for all of my instance variables. But, I was wondering what happens when something does change. After reading the above passage, I got it. Don't design for that hook until you NEED IT. In other words, don't code for change until it happens!
Post a Comment