A principle is something you follow blindly, something that doesn’t need a judgement call, and these do exist. Stuff like “Don’t use goto”, “Structure your code well”, “No compiler warnings” and so on.
Something like the Liskov substitution principle.
That’s why modern guidelines and styleguides separate stuff into “must” and “should”, and a principle is always a must.
I think you could be assuming a different definition of “principles” than Bob Martin was when he wrote them.
They weren’t “principles” like “a basic law or assumption.” It’s the second definition, principles as “a standard of good behavior.” (Such as in Cambridge’s definition here).
That is, using the “should” and “must” phrasing, I’ve always felt the SOLID principles were obviously more “should” than must. Good behavior is “should” but not something you follow blindly.
Not sure if SOLID was meant as “should”. At least when I was at university it certainly was taught as “must” and a lot of coworkers of mine also treated it as “must”.
But anyway, it’s super old stuff. SOLID was created in 2000. That’s a quarter century ago and a ton has changed since.
Even Clean Code will be 17 years old this year. It’s time to revisit all that, and most of it is just not nearly as good as it looks.
I’ve never met a decent, experienced developer who held these as incontrovertible truths. Lots of junior developers for sure. Maybe that’s a lot of what’s left.
Experience proves that holding a dogmatic view of “musts” for things like this is frequently an issue in itself. Maybe it’s time everyone tried to learn that lesson again.
I think simple “musts” can be helpful on an organizational level to synchronize work. Stuff like “must use one of the approved languages”, “must use git”, “must use a linter with a given preset”, “must get rid of all compiler warnings”. That kind of stuff just makes working together easier, but neither of them are dogmatic truths but just stuff to make organization and working together easier.
But I agree that dogmatic views for broader subjects are very often harmful but at the same time rarely bring a lot of benefit. I’ve worked at a project before where the former lead dev was a really bad and dogmatic developer who managed to get to this position through intimidation. He followed “Clean code” to excessive lengths, which meant that it was quite common that a simple 1 Story Point change required touching 40+ files. Hardly any method was longer than 5 lines, hardly any class had more than one method, everything was split up like crazy.
Imagine writing code, but instead of lines you use classes instead.
I have met quite a few long-term developers with senior titles and sometimes even lead dev or architect titles who follow dogmatic views to the extreme.
I agree that no decent developer would, but that’s a bit of a circular definition (since being dogmatic precludes you from being decent).
And I totally wished universities would be better at explaining that design principles are decent guidlines if you don’t have any other basis to make a decision, but that they are ultimately tools in a toolbox and a good developer needs to understand when to use them and when not to.
Too many people come out of university thinking that SOLID or Clean Code are the bible.
A principle is something you follow blindly, something that doesn’t need a judgement call, and these do exist. Stuff like “Don’t use goto”, “Structure your code well”, “No compiler warnings” and so on.
Something like the Liskov substitution principle.
That’s why modern guidelines and styleguides separate stuff into “must” and “should”, and a principle is always a must.
I think you could be assuming a different definition of “principles” than Bob Martin was when he wrote them.
They weren’t “principles” like “a basic law or assumption.” It’s the second definition, principles as “a standard of good behavior.” (Such as in Cambridge’s definition here).
That is, using the “should” and “must” phrasing, I’ve always felt the SOLID principles were obviously more “should” than must. Good behavior is “should” but not something you follow blindly.
Not sure if SOLID was meant as “should”. At least when I was at university it certainly was taught as “must” and a lot of coworkers of mine also treated it as “must”.
But anyway, it’s super old stuff. SOLID was created in 2000. That’s a quarter century ago and a ton has changed since.
Even Clean Code will be 17 years old this year. It’s time to revisit all that, and most of it is just not nearly as good as it looks.
I’ve never met a decent, experienced developer who held these as incontrovertible truths. Lots of junior developers for sure. Maybe that’s a lot of what’s left.
Experience proves that holding a dogmatic view of “musts” for things like this is frequently an issue in itself. Maybe it’s time everyone tried to learn that lesson again.
I think simple “musts” can be helpful on an organizational level to synchronize work. Stuff like “must use one of the approved languages”, “must use git”, “must use a linter with a given preset”, “must get rid of all compiler warnings”. That kind of stuff just makes working together easier, but neither of them are dogmatic truths but just stuff to make organization and working together easier.
But I agree that dogmatic views for broader subjects are very often harmful but at the same time rarely bring a lot of benefit. I’ve worked at a project before where the former lead dev was a really bad and dogmatic developer who managed to get to this position through intimidation. He followed “Clean code” to excessive lengths, which meant that it was quite common that a simple 1 Story Point change required touching 40+ files. Hardly any method was longer than 5 lines, hardly any class had more than one method, everything was split up like crazy.
Imagine writing code, but instead of lines you use classes instead.
I have met quite a few long-term developers with senior titles and sometimes even lead dev or architect titles who follow dogmatic views to the extreme.
I agree that no decent developer would, but that’s a bit of a circular definition (since being dogmatic precludes you from being decent).
And I totally wished universities would be better at explaining that design principles are decent guidlines if you don’t have any other basis to make a decision, but that they are ultimately tools in a toolbox and a good developer needs to understand when to use them and when not to.
Too many people come out of university thinking that SOLID or Clean Code are the bible.