Writing good software is hard. Fortunately, we can borrow from our everyday life experiences to make it easier.
Consider the following situation:
You're sitting at your desk writing some C# when your stomach signals to your brain: "Hey, I need some food so we can continue to function normally."
Your brain signals your imagination and your imagination suggests: "Let's get a burger."
Your brain analyzes the suggestion, concurs, and directs the rest of your body out the door to your local neighborhood Bob's Beefy Burgers.
5-15 minutes later...
You're at Bob's Beefy Burgers counter and you say to the cashier: "One Bob's Big Beefy triple with cheese please."
The cashier asks: "Would you like just the sandwich or the entire meal for an extra $1.95?"
(Now this is where it gets complicated, so pay attention.)
You process the cashier's question and consider your options like so:
- Meal means fries and Pepesee
- I like fries and could eat some
- I like Pepesee and could drink some
- $1.95 is not that much, I can afford it
And so you answer: "The meal"
10-20 minutes later...
You still have about 4-5 bites of sandwich in your hand, about 12-18 fries on the tray, and 8 ounces of Pepesee in your cup. You are also full and can eat no more and drink no more. You throw away the extra food and are $1.95 (plus tax) poorer than you would have been had you simply ordered only what you needed in the first place.
So consider this analagous situation:
You're sitting at your desk writing some C# when your buddy signals to you: "Hey let's write a class that connects to a database so we can do some stuff."
Your brain signals your imagination and your imagination suggests: "Let's write a DatabaseConnection class".
Your brain analyzes the suggestion, concurs, and directs your fingers to spin up a new class.
5-15 seconds later...
You're looking at the first set of tests and code, respectively called DatabaseConnectionTest and DatabaseConnection. The DatabaseConnection constructor takes one parameter called connectionString so that users can specify the location of their database.
Your buddy asks: "Should we make that parameter optional?"
(Now this is where it gets complicated, so pay attention.)
You process your buddy's question and consider your options like so:
- Default empty string means clients don't have to know where they're connecting to when they instantiate this class
- People like not having to know stuff when they do things
- People like options when doing things
- Making the parameter optional is 30 seconds of work, I can do it
And so you answer: "Make it optional"
10-20 weeks later...
Your DatabaseConnection has grown popular. It is now being used in 5 services across your project and referenced in 20 files altogether. You are considering refactoring your class slightly, but need to know how it's used when instantiated without that optional parameter. You waste 30 minutes wandering through your entire project looking for usages of this constructor without a parameter and running all your specs just to find out that, well, there aren't any.
You throw away the optional parameter and are 30 minutes behind where you would have been had you simply written only what you needed in the first place.
Moral of the Story
If you don't need it, then don't buy it, don't write it, don't think about writing it. We've all heard it before, just need a reminder every once in a while. So just say no, do what you really need to do, and live a good life.