Think twice before abstracting code #programming

When a software architect or any programmer thinks about abstracting code, there are some hidden costs. Though the pattern you introduce may seem simpler on the surface, what happens when another software engineer needs to dig into your abstraction? Often the complexity we introduce when we create a software development abstraction in some pattern, framework, or library can actually create more problems than we intended.

#softwaredevelopement #softwareengineer #programmer

[lodevijk]

Every single design patern has one disadvantage: increases code complexity. You can write very simple non-SOLID code that performs super fast. The problems arise later.

[nickvledder]

Another big thumbs up for one of your great videos!

[samfrostinjapan]

I wish the programmers in Japan realized this kind of thing more. I think the tendancy to work at one company for longer than US and other coutnries makes them feel okay with making way too many layers of abstractions that feel fine to them because they have 10+ years of context with the codebase.

[petergyt]

This is a trade-off: never assume one solution or its opposite is ideal without putting a little thought into it.

Basically abstractions are essentially black-boxes that, if I am not familiar with their construction and or purpose, I now have to take time out to figure out what they do and what, if any underlying "gotchas" might be involved with their use.

[siclvceatlvx]

I've reached the point where I won't abstract anything unless it is absolutely certain the functionality needs to be reused next week. If it's been two weeks, I will perhaps consider refactoring. I'm currently stuck with a bunch of devs who will demand absolute abstraction of anything before approving any PR i submit. Guess they are not in the business of delivering anything resembling value to the end user but just want to be pure and pristine or whatever. Tech equivalent to holier than thou priests in a temple.

[Jollyprez]

I completely "grok" the concept. Abstractions ALWAYS create complexity. The trade-off is whether the added complexity gets canceled-out by the utility of the abstraction. In MY opinion, the "pattern" paradigm - abstractions - have overwhelmed software engineering and we have gratuitously complex systems, full of "patterns" that get ever more incomprehensible, and difficult to maintain.

[Georgggg]

Is this recent trend, that people started suspect something wrong about object hierarchies, and other DRY dogma implementations?

[PaulSebastianManole]

It depends. If an abstraction is fixing a problem seen very often like all over the place in a code base then it's worth learning and having. The abstractions I have hated the most are those introducing magic that is prone to runtime errors like AutoMapper. Ugh! 🤢

[dolevdo]

This is so hard to explain to my boss, china team library are so hard to understand

[GilAguilar]

I like this, thanks for always sharing your valuable insight ☕️

It’s easier to just dump a bunch of code into an existing legacy application.

To meet tight deadlines, fake agile we’ll get the best of anyone. So the file will be like a gazzillion lines of code 😂

You’ll eventually need to abstract the code to make it easier to follow and in the process introduce something new.

It becomes a constant explanation, which eventually makes you consider your own approach.

Reason why I use jsdoc in my JS or the equivalent in PHP.

You’ll get to the point in any code base where it will need to abstracted in order to make it more modular.

So it is easier to scale and needed to decouple the areas being updated.

It’s a love and hate relationship 😁

When all else fails, it’s coffee time 💙🤟☕️