ORM's are yet another instance of "Big Dark Grey Boxes" (BDGB). They are powerful tools that do a lot for you IF they work as intended. When they don't, you have to experiment and fiddle, and perhaps end up fudging up an ugly work-around to meet deadlines.
Templating engines (like Razor), UI formatting engines (Bootstrap), and routing engines (URL path translation) are also BDGB's with a similar great-until-broken profile.
I most cases it seems we can could have simpler versions that are only a few hundred lines of code. If this few hundred can generate 90% of our SQL or whatnot, then we get most of the time savings without the complexity: we can study or fix a few hundreds lines of code. Chasing that last 10% has created these bloated BDGB monstrosities. Leave it at 90% and enjoy simplicity. It seems components have a handling-curve something like this:
80%: 100 LOC (LOC = lines of code)
90%: 250 LOC
95%: 1000 LOC
98%: 3000 LOC
99%: 6000 LOC
The percent value here is the percent of situations the component handles. In ORM's case, it would be the percent of SQL code generated by the component.
We should strive for components that assist us with grunt-work, not hide the process of doing it behind too much code to grok. If it's simple enough, we can also tune it to better fit shop conventions.
For big development shops, it may make sense to assign specialists to master BDGB. If they work with it all day, they'll eventually figure out most of its quirks and oddities. It's specialization at work. But smaller shops often waste too much time trying to troubleshoot irksome BDGB's because they don't have time to focus on any one.
Templating engines (like Razor), UI formatting engines (Bootstrap), and routing engines (URL path translation) are also BDGB's with a similar great-until-broken profile.
I most cases it seems we can could have simpler versions that are only a few hundred lines of code. If this few hundred can generate 90% of our SQL or whatnot, then we get most of the time savings without the complexity: we can study or fix a few hundreds lines of code. Chasing that last 10% has created these bloated BDGB monstrosities. Leave it at 90% and enjoy simplicity. It seems components have a handling-curve something like this:
The percent value here is the percent of situations the component handles. In ORM's case, it would be the percent of SQL code generated by the component.We should strive for components that assist us with grunt-work, not hide the process of doing it behind too much code to grok. If it's simple enough, we can also tune it to better fit shop conventions.
For big development shops, it may make sense to assign specialists to master BDGB. If they work with it all day, they'll eventually figure out most of its quirks and oddities. It's specialization at work. But smaller shops often waste too much time trying to troubleshoot irksome BDGB's because they don't have time to focus on any one.