Between Theoretical concepts & Practical implementations

As a software developer who’s been in this career for almost a decade, I’ve read about a lot of concepts that were invented to help humanity, and save their time in innovating and creating software.

And if you are in this journey, or know someone who is, most probably you’d have heard about concepts like, OOP, SOLID, DRY and, KISS etc..

Then you’ll find two major camps regarding those principles, old schoolers who’d die defending those concepts under the flag of “best practices” and, the free riders who wouldn’t mind go against all or some of those concepts trying to avoid what they call “over-engineering”.

Beside other fundamentals we usually read about in online articles e.g. Design Patterns, SDLCs like Agile and waterfall, etc..

And we poor souls — programmers — who consume caffeine and, turn it into some functional useful software — with a bit of sarcasm as a side effect — get overwhelmed by the lot of these concepts — despite the fact of the fierce continuous fight we have among one another for the Right Way ™️ of software development.

It seems that there is an eternal gap between theory and practice, and that gap is significant with the extremists who belong to either of the camps mentioned earlier, the book worms — who are avid readers pursuing academic path or study, or who just falsely think that reading begets experience — and, on the other side the non-reading adventurers who favor practice over theory by the “trial by error” approach — I’m guilty of leaning towards this side and, believe me my life is tough because of this and, learning things the hard way is truly difficult but, sometimes it pays off.

As most of my writings in different fields of life, I’ll advise you here too with the same piece of advice I give in every field, the key is to “find balance” and, “raise your awareness” i.e. read books relevant to your field of software development — to gain knowledge — and, try applying what you’ve learnt in resolving your real world problems — to gain experience — , while being critical of what you read and practice, so that you mix and match different concepts and fundamentals in the way that serves you best.

“There’s a difference between knowing the path and, walking the path.”

— The Matrix (1999 Movie)

Generally in software, there is no “silver bullet” solution to every problem, a problem can have a multitude of different potential solutions, each of which has its pros and cons so, no answer is perfect and, no technology can handle every scenario and use case, thus we have restricting fundamentals like SRS — Software Requirements Specification — and, project scoping.

“Any program that tries to be so generalized and configurable that it could handle any kind of task, will either fall short of this goal, or will be horribly broken.”

— Chris Wenham (Software Developer)

Therefore, questions like “What is the best programming language?”, “Why do you prefer Laravel over Symfony?”, “Angular, React or, Vue?”, “.net, Python, node or, php?”, “nginx or apache?”, “VPS, cloud services aka serverless, kubernetes or, docker?” and, a lot of other similar questions, all should be answered “it depends!”.

Even questions related to the process of coding itself regarding OOP and, design patterns should have the same answer, we need to stop this unnecessary ludicrous debates on which is better and, rather define the factors which will help us decide the most “suitable” approach, technology stack or, deployment plan that would serve the required purpose or, provide the solution to the given problem.

In conclusion I’d like to list some of the factors that might lead a team to a particular direction rather than others, regarding programming languages, required libraries and frameworks, deployment and infrastructure and, even third party services that might be needed, the factors that I could bring off the top of my head are:

• Current skills set and experience of the team involved.
• Some of the software requirement specifics.
• The available budget provided for the project development.
• Potential talents available in the market to recruit when needed.

These factors are too general nonetheless, it gives a hint about what type of challenges a software related team or organization would face and, how to overcome them, and remember, every scenario, individual and, team is unique so, any decisions taken should consider the needs of both sides: the stakeholders and, the execution team(s).

Lastly books, courses and, other knowledge sources are helping guides that simplify the process however, they should never be blindly followed thus, picking and mixing up different concepts should be okay to some extent, as long as proper thought is given to find what suits you best. And what works with you does not necessarily work with other folks.