September 7, 2022 at 12:00 am
Comments posted to this topic are about the item Developer Optimism
September 7, 2022 at 6:30 am
DBA cynicism
Developers don't need to know SQL, they only need to know Entity Framework or some other ORM.
ORMs allow them to ship code faster and that is their sole criterion. That the SQL being executed is mediocre, will cause deadlocks and is hell to debug is neither here nor there. That is somebody else's problem.
We recently had a sprint where the developers went out of their way to replace the remaining stored procedures in the DB with Entity Framework code despite the fact that the SPs were not a performance problem. The only reason to get rid of them is so that the developers *don't* have to deal with SQL. And, as it happened, performance is slightly slower as a consequence. But the developers don't mind. They do what they like and they can as long as they hit the sprint deadlines.
The primary problem is management. They tolerate mediocre performance and they set the standards.
As long as we rely on Full-Stack-Developers, SQL will go the way of the dodo. Sure, like COBOL, there will always be a demand for it somewhere, but while SQL may be ubiquitous, ORMs have made direct knowledge of SQL merely a nice to have.
September 7, 2022 at 1:13 pm
I always found that the worst case of developer optimism was in validation and error handling. The assumption was that if it got through the front-end all was well.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 7, 2022 at 1:20 pm
Been a developer for 25+ years...I'm no longer optimistic.
September 7, 2022 at 1:25 pm
Ok, I am a developer, and I have to say I hope Sean Redmond is being facetious.
This is one of my pet peeves. I'm a lone-wolf developer, I have no one else to turn to, making me the DBA, the front end developer, the services developer, and trouble-shooter.
I've been in the business for over 40 years now. My advice to front end developers who have the luxury of SQL server specialists: use them! Let them handle database design, stored procedures for CRUD, constraints and all the other bric-a-brac of storing data. They know how and they're good at it.
Likewise, to those data specialists. Let the developers handle the front end. Let them deal with the minutia of user experience. Give them an API and let them go.
Finally, to the lone wolves like me. No way around it. You have to learn both worlds. Treat them both with full respect. Database programming/design is an art and science. So is UX. So is coding. Treat all of it as worthy of study in depth.
But, and this is crucial, keep it simple. On both sides. The less there is the less that can go wrong.
If you're going to do DB applications, either specialize and let the other specialists do what they do best, or if you do it all you have to learn it all.
September 7, 2022 at 1:38 pm
roger.plowman» and I have to say I hope Sean Redmond is being facetious.
I wish I were. I am just angry. I completely agree with you.
Still, I'm learning tabular models to keep my work interesting since database performance is no longer really a consideration and I'm wondering when the hundreds of deadlocks that I see reported before me will make someone either higher up or amongst the developers realise that all is not well. It seems that isolation level serializable is not the most ideal isolation level.
September 7, 2022 at 2:18 pm
Sounds like your devs don't know how to use your ORM properly. That's a shame. ORMs semm to often be touted as a "silver bullet" to solve all your database programming woes ("looky! we don't have to write any database code"), but I've found that when using an ORM (Entity Framework in my case), I end up writing the same database code (stored procs and views) that I would have written, even without the ORM. An ORM, used within its capabilities and limitations, can be quite helpful. Unfortunately, too may developers don't seem to understand how to use them well, or when it's better to not use one.
September 7, 2022 at 2:20 pm
Lol, I love Sean's response, and sorry that things have gotten you upset, Sean.
Too many developers are like this, but lots aren't. As I move about between customers and clients, they alternately sadden and excite me. Lots of them are trying to be better, even though many don't like working through complex SQL.
September 7, 2022 at 3:13 pm
I am a developer. And I have to admit that I've been guilty as described in Steve's editorial.
However, I also will say that as I've gotten older, and hopefully a little wiser, some of my ideas have changed. At the start of my career I was all for writing everything we used. I bought into the "Not invented here" ideology. About 10 years ago I realized that no one will live long enough to write everything one needs to use, so go ahead and use something written by someone else. Heck, I'm even up for buying it, if it works for us. If a commercial or open source project does the job, then YEAH! Onto the next issue.
Kindest Regards, Rod Connect with me on LinkedIn.
September 7, 2022 at 3:43 pm
"
The primary problem is management. They tolerate mediocre performance and they set the standards.
As long as we rely on Full-Stack-Developers, SQL will go the way of the dodo. Sure, like COBOL, there will always be a demand for it somewhere, but while SQL may be ubiquitous, ORMs have made direct knowledge of SQL merely a nice to have."
Very true and very sad.... Except for ORMs.It is like comparing skill to use pocket calculators with knowing mathematics. I have a feeling the SQL is taught less and less in schools.
Zidar's Theorem: The best code is no code at all...
September 7, 2022 at 5:31 pm
I think a big part of the problem is management and not holding people accountable. However, there is also personal responsibility and professionalism, which can be lacking.
September 7, 2022 at 7:58 pm
I think a big part of the problem is management and not holding people accountable. However, there is also personal responsibility and professionalism, which can be lacking.
I agree Steve. Even having been an IT manager for 11 years, I think that especially more recent managers are a large part of IT problems. In my last position the company hired a number of 'project managers' to be reponsible for ongoing large application areas. The problem was that they were 'managers' but not 'technical managers'. Most of them were fairly young, younger than the rest of us, had little experience and and some no IT background at all, so had zero empathy for what they were 'managing' and the technical folks they 'managed'.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 7, 2022 at 8:35 pm
Really, really good SQL Developers are pretty much superflous...until you really, really need one.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 8, 2022 at 2:11 pm
Steve Jones - SSC Editor wrote:I think a big part of the problem is management and not holding people accountable. However, there is also personal responsibility and professionalism, which can be lacking.
I agree Steve. Even having been an IT manager for 11 years, I think that especially more recent managers are a large part of IT problems. In my last position the company hired a number of 'project managers' to be reponsible for ongoing large application areas. The problem was that they were 'managers' but not 'technical managers'. Most of them were fairly young, younger than the rest of us, had little experience and and some no IT background at all, so had zero empathy for what they were 'managing' and the technical folks they 'managed'.
Rick, I've got a question for you about managers who haven't got an IT background. In my current job I'm seeing people become managers who have no IT experience. (Not my boss, he does have IT experience.) I don't have much interaction with these folks, so I can't say what they're like, but it seems like they've all got managerial experience. I'm getting the feeling that they're got either a business administration degree or MBA, so they (presumably) know how to manage people and business situations. What do you see as their shortcomings?
Kindest Regards, Rod Connect with me on LinkedIn.
September 9, 2022 at 1:44 am
skeleton567 wrote:Steve Jones - SSC Editor wrote:I think a big part of the problem is management and not holding people accountable. However, there is also personal responsibility and professionalism, which can be lacking.
I agree Steve. Even having been an IT manager for 11 years, I think that especially more recent managers are a large part of IT problems. In my last position the company hired a number of 'project managers' to be reponsible for ongoing large application areas. The problem was that they were 'managers' but not 'technical managers'. Most of them were fairly young, younger than the rest of us, had little experience and and some no IT background at all, so had zero empathy for what they were 'managing' and the technical folks they 'managed'.
Rick, I've got a question for you about managers who haven't got an IT background. In my current job I'm seeing people become managers who have no IT experience. (Not my boss, he does have IT experience.) I don't have much interaction with these folks, so I can't say what they're like, but it seems like they've all got managerial experience. I'm getting the feeling that they're got either a business administration degree or MBA, so they (presumably) know how to manage people and business situations. What do you see as their shortcomings?
Rod, in this situation, I don't think the project managers had any advanced degrees or training or experience, but basically served simply as the non-technical front line in interacting with users of their respective applications. The problems arose when there were things, usually in terms of bug fixes or internal improvements that needed to be done but they would not get on board with getting this kind of thing done because it was seen - by them - as risky to the status quo. Thus we had things 'sitting on the shelf' for periods of time, which often we had to slip in without official management sanction. Understand that the protocol required that anything and everything was (supposed to be) documented and approved before implementation.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply