The main reason for writing this post is that developers usually have some kind of bias against other programming languages or workflows, specially against those that they don’t know/understand/use… it’s always the same debate: dynamic against strict, strong-typed against loosely-typed, compiled vs. processed, sexy, powerful, expressive, safe, fast, etc..
My point-of-view is based on these principles:
- We always have something new to learn from other developers
- specially from those who are building applications more complex than the ones we are building, but not exclusively.
- There is no perfect language or perfect workflow
- most of the things vary based upon your preferences and scope of the project.
- We can’t have everything at once…
- we always need to sacrifice something in exchange of something that we value more.
When you have more than 30 developers working full-time in a single application writing hundreds of thousands lines of code you need to follow a work-flow completely different than someone that is building an application that has ~10.000 lines of code written by 1-3 developers and specially from someone that is building an application with less than 1.000 lines of code by himself, even the client and use of the application changes the methodologies/tools that you should use, it isn’t only about the size/complexity, but also about the goals… You can’t code a system for a large bank on the same way you code a blog for a small shop, it would be unpractical and conceptually wrong…
The “bias” problem
Enterprise developers have their reasons to do things the way they do as well as developers that works on a small team and with simple projects, nobody is completely right or wrong when you talk about these things specially when the scope is different… People have different needs and problems that they need to solve, so it’s more than common that they disagree about the proper approach, you can’t compare the problems that an Assembly Language developer that works coding drivers is having with the ones that a PHP developer that is mostly doing CMS experienced so far, it’s like comparing bananas to oranges.
Learn why things were created so you can judge when to use them
Object Oriented Programming, Test-driven Development, Continuous Integration, Functional Programming, etc, where all created with the same purpose, solve specific problems that a specific group of people were encountering at a specific moment, yeah it’s really specific, that’s why I repeated it so much, it doesn’t solve all problems and it isn’t the best approach for every single occasion…
A smart person learn from other peoples’ mistakes
I really believe that the developers of static/strong-typed languages have a lot to learn from the dynamic languages community, specially how to be productive and to work on a fast-paced environment keeping things simple and caring less about the maintainace/organization of the code, however, the dynamic/loosely-typed developers, have a lot to learn about how to keep the code organized/better structured and how to build scalable/maintainable applications while working with a large team… – Everybody has something new to learn.
There is no “universal” approach
I used to believe that the more academical/technical approach was always the right choice for any kind of project/problem, but after sometime coding and looking at other people’s code I started to realize that it depends on a series of rules: the scope of the project, number of developers working together, client, expected lifetime of the application, etc. You shouldn’t use the same workflow if you are building a completely different kind of application…
The “a little bit more complex” rule
Another thing that I kind figured out after some time following blogs from many different developers of different languages/skill-levels is that the opinions that made more sense for me (at that specific time) usually came from people that where building things “just a little bit more complex” than the ones I was building.
People that are building applications 10x more complex are probably experiencing problems that I’m probably not going to encounter anytime soon, so their opinion was more a heads-up for the future than actually something useful/important for the present. If your website is far from being on the top 100 Alexa rank then you shouldn’t be caring about the same things those people are, your problems and goals are different…
We should always try to foresee problems and build things following as many best practices as we can, but it’s also important to fully understand our needs to avoid over-complicating a project without need and most important, find the balance between “speed” and “safety”, which I think it’s the hardest part of being a developer.
It’s a key factor to understand why people created those rules and which kind of problems they solve/create so you can decide when to bend them, always remember:
“There is no spoon”
I hope that at least a couple people stop being so biased against other languages/workflows just because they don’t fit their current needs… I’m sure things won’t change that easily, but at least I’ve said something…