Building apps so that you never have to invest a moment of your time again into fixing, upgrading, and maintaining them. Sound familiar?
Nope, because it’s not an option.
A lot of people seem ultra obsessed with building interfaces on interfaces, abstracts for abstracts for abstracts, packages that move an implementation away from an implementation, and then again away from an implementation. The common excuse is making sure you can switch out packages, frameworks, libraries on a whim later on - but can you really? Is it really faster / better to write another adapter for an interface, than to rewrite 4 lines of tightly coupled code?
Both camps are very vocal, and I personally do what feels right at the time, not blindly following a doctrine because it’s currently popular, so I can’t help but subscribe to both opinions at the same time, depending on context. The post linked at the beginning makes an interesting point:
If you want a future proof system, you don’t want immortal and flexible code. You don’t want the T1000 terminator. You want Southpark’s Kenny. You need code that’s easy and fun to kill. You need to get used to killing it, often, so you can replace it with whatever you end up needing.
And…
“Hard coding” implementation or even values is not a problem if you have a development process where your code is maintained and released regularly. In fact, it can lead to clearer code that’s easier to work with.
That, I believe, is the gist of it.
An excellent and hilarious example of interface absurdity is the Enterprise FizzBuzz - a programming interview question usually solvable in one one to five lines of code, in this case built with several dozen classes on top of interfaces and a variety of other complexities I couldn’t even begin to pretend to understand (or want to understand).
How do you feel about this? Do you interface 'till kingdom come, or do you generally hack away to get to the solution and then expand with “extensibility” later (if at all)?