Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "Solid Programming - No Thanks" video.

I totally agree that you shouldn't abstract before actually feeling the need for it. Say you abstract your invoice printing from the start to support printing to JSON and stdout. However, when the boss then says you have to support HTML, too, and by the way, HTML needs company header, you have to redo every abstraction you already did for the printing stuff so support injecting the extra information to pass the header without using hardcoded header or global configuration values. And the same thing for every other extra dependency what your future data print needs might be. I know I've done lots of unnecessary abstractions during my career and it's not an accident such thing is called astronaut architechture: you try to guess what kind of interfaces you might need if this specific feature would be used by NASA during the Mars mission. And since you cannot possibly guess that correctly, you'll always miss something and have something extra that even the Mars mission is not going to need.
2
@duke54762 As I wrote, when requirements change after the fact, you always have to modify existing code one way or another. The astronaut architecture design means that you try to guess which extensions might be needed in the future and you try to design the printer interface generic enough to support HTML in the future even if it's not needed in current requirements. And it might be that the future requirement is not HTML but PDF which requires totally different API. My point was that you shoudn't try to guess about future requirements. Obviously, you should try to keep dependencies between all the modules as simple as possible but do not make the newly designed interface between the modules more complex than what you actually need right now. Otherwise you'll just end up with more complex API that will not match the unexpected future requirement change anyway.
1
13:40 If you really create yet another class to print an invoice, and then yet an another class to print book details etc etc you end up with totally insane amount of classes. Sure, you only need to modify one class at a time but having insane amount of concepts (classes in OOP) is not free either.
1
@duke54762 My point was that if you're printing a simple text output, you only need to include actual text data into the stream. When requirements change and you now want to emit extra information such as images of the products, use custom fonts, use department letterhead and change the output from HTML to PDF, the API will look a lot different because the existing data is not enough. You could try to foresee this requirement from the start and add extra objects to the API that allow defining style and object photos and whatnot and you'd end up guessing wrong.
1
I think any development method should be considered as guidelines instead of strict rules. Absolute rules are always a problem because any simple set of rules is never going to work for everything. I liked the star navigation idea. SOLID (or other methodology you try to follow) should be considered a rough target but if you hit a mountain, it's wiser to go around it than through it just to keep your direction perfect. Just make sure you make known decisions when you differ from your target method. You shouldn't make exceptions accidentally.
1
20:05 And if you're writing really SOLID code, you wouldn't have a class than do both persistence to files and persistence to database, right? As a result, you immediately have to have some kind of interface class and then to implementations for it. Instead of writing two functions in a single class! Adding more flexibility does add complexity to your code. And I think every experienced developer would agree that additional complexity is definitely not what we want.
1