November 15, 2017 at 9:39 pm
Comments posted to this topic are about the item Start Fixing Your DB with Better Code
November 15, 2017 at 10:12 pm
If you know the product you're working with, you will always save some time doing it right the first time. If you don't know the product you're working with VERY well, then doing it right the first time will save a HUGE amount of time later.
As the infamous "Red" Adair has been quoted as saying, "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."
Seriously... most people, especially managers that aren't "in the know", just don't understand that the upfront cost of doing something right is relatively minuscule to releasing something that isn't. Rework, retesting, and re-release all have costs. If something you released caused inconvenience, agony, or harm to a customer, the hidden cost in bad advertising in the elevators and on the golf courses could cost big time.
To use another relevant quote "Whatever is worth doing at all, is worth doing well." (-- Philip Stanhope, 4th Earl of Chesterfield)
In direct contrast to that, I like to remind managers of what to expect on any given project with a saying of my own... "If you want it real bad, that's the way you'll get it". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2017 at 1:39 am
Preaching to the choir!
I think a substantial part of the problem is the lack of leadership, mentoring and guidance. The biggest accelerators for my career have been a surprisingly short period of time with a mentor.
My first exposure to SQL Server was the two SQL6.5 courses but the trainer was a grizzled veteran who got us through the courses in 3 days rather than 5. The spare 2 days were spent teaching us what we REALLY needed to know.
I had a couple of weeks learning OO, again from a veteran. I learned more in those 2 weeks than I had in 5 years in various development jobs.
Same with management training. The right person can act as a catalyst and an inspiration. When you have worked under good leadership and that leader moves on it's amazing how fast an organisation goes into decline. Culture and behaviours really do come from the top.
No-one sets out to do a crap job. Most people want to do the right thing. They shouldn't have to blunder around for years until they stumble across the right way of doing something.
November 16, 2017 at 6:55 am
I think the reasoning behind the adage that "it takes about as long to do something right as wrong, so do it the first time" is that, while, yes, it takes time to 'do it right', with the planning etc. you have to add to the time to 'do it wrong' all the time it takes to fix the code. Also bear in mind that often it is not the original author that has to fix it so you can add in time for the 'fixer' to work out what the original code was trying to do in the first place.
Taking all that into consideration, I believe it is actually cheaper to invest in good code from the outset. You will definitely save money in the long run.
November 16, 2017 at 7:19 am
But how do you know if your code is right or wrong when the examples to learn from don't scale or are not complete? Most articles I find on writing better code never actually explain how or give valid or complete examples that can scale. Some even have code that won't compile for various reasons which is problematic when the reader is trying to learn how to do something they know nothing about.
November 16, 2017 at 7:27 am
No-one sets out to do a crap job. Most people want to do the right thing.
Not entirely sure about this, or perhaps it's just a disagreement about what the right thing is. I've had disagreements with programmers because they don't want to enclose items that must occur together in a transaction because it doesn't perform as fast as without the transactions. Then later we have issues with inconsistent data. They didn't intend to do the wrong thing, but the right thing they intended was not the correct thing to intend as an overriding factor. At my last job I had disagreements with the architect who eschewed primary and foreign keys because "the ETL took care of it." Even on finding inconsistencies he would just say something was wrong with the ETL. He didn't intend the bad, but he passed on the proper methods for enforcing RI. (I've had similar discussions with people on this site who also forgo the RI constraints for the same reason). All too many want to do their thing, not the right thing.
November 16, 2017 at 7:30 am
cmick 77911 - Thursday, November 16, 2017 7:19 AMBut how do you know if your code is right or wrong when the examples to learn from don't scale or are not complete? Most articles I find on writing better code never actually explain how or give valid or complete examples that can scale. Some even have code that won't compile for various reasons which is problematic when the reader is trying to learn how to do something they know nothing about.
You bring up a very good point. In fact, I'll say that a large part of the Internet actually shows you how to do it wrong because the people writing the blogs (or whatever and some carry both big names and big company names) just don't know the right way to do things. The old saying of "The Internet is a well paved onramp to a dirt road" is frequently still applicable.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2017 at 7:31 am
Oooh, you just hit my berserk button. 🙂
First, the initial problem is at the student level. They learn the bare minimum and get kicked out the door. Everybody who's been around for 5+ years knows they teach you squat in classes. The classes are crap, not because of greed or laziness, but because *they don't give students enough time*.
It takes a LOT of time to let basics like variables, control flow, encapsulation, etc. to become instinctive knowledge (probably 2 years). But those are just table stakes. Every language has its own paradigm, it's own best practices. Learning those (even in a concentrated mentor environment) can take another two years. Just to become fluent in the language. That's not "mastery" that's "fluency". Fluency is the table stakes of being a professional developer.
Take any .Net language and compare it to T/SQL, for instance. In terms of paradigm you might as well be talking sub-atomic physics vs behavioral psychology. The two approaches are really that different. Yet we expect developers to know and master both.
Oh, and halfway through the project the database gets switched to MariaDB? Yeah, that will end well... Least Common Denominator for the win!
Truth is, most developers or DBAs aren't even fluent in their disciplines of choice. Training is non-existent (or might as well be) because companies don't want to take the time or spend the money.
"Why don't you already know this stuff? We're paying you a fortune and you *don't know this stuff?????!!!!!!*"
Thus spake PHB...
Any classes that the developer or DBA sneak in are quickies and have the same lack of time issue as basic CompSci classes. Sigh.
It also doesn't help the vendors are spewing out new changes, new features, new whiz-bang-golly-gee buzzwords at an ever accelerating rate. Most of which are useless to most developers but excite the clueless. Sigh.
And speaking of management, how can you manage something when you don't know anything about it? Training isn't just for developers you know!
It's enough to make you cry, it really is.
November 16, 2017 at 7:40 am
RonKyle - Thursday, November 16, 2017 7:27 AMNo-one sets out to do a crap job. Most people want to do the right thing.
Not entirely sure about this, or perhaps it's just a disagreement about what the right thing is. I've had disagreements with programmers because they don't want to enclose items that must occur together in a transaction because it doesn't perform as fast as without the transactions. Then later we have issues with inconsistent data. They didn't intend to do the wrong thing, but the right thing they intended was not the correct thing to intend as an overriding factor. At my last job I had disagreements with the architect who eschewed primary and foreign keys because "the ETL took care of it." Even on finding inconsistencies he would just say something was wrong with the ETL. He didn't intend the bad, but he passed on the proper methods for enforcing RI. (I've had similar discussions with people on this site who also forgo the RI constraints for the same reason). All too many want to do their thing, not the right thing.
I've also found that a large part of the problem is that people just don't give a damned if they turn out crap code or not and will fight you tooth and nail just so they can get it off their plate. Then, they go home at 5 and do nothing to teach themselves more about the trade(s) that are putting food in their kids mouths or allowing them enough money to not actually have to live with their parents. 😉
Another pet peeve of mine is that online free training (although not all of it is good) is certainly available in this industry but a lot of people will only work or train from 9-5 and will do nothing on their own to get better at things. Hell... if you look at the posts on this forum, a lot are incredibly basic and people won't even do a search on Yabingooglehoo to see what they can find on their own. I do understand that there's a lot of real junk out there but a whole lot of people won't even try a lookup for the correct syntax of something where the Microsoft BOL version normally bubbles to the top.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2017 at 7:50 am
roger.plowman - Thursday, November 16, 2017 7:31 AMOooh, you just hit my berserk button. 🙂First, the initial problem is at the student level. They learn the bare minimum and get kicked out the door. Everybody who's been around for 5+ years knows they teach you squat in classes. The classes are crap, not because of greed or laziness, but because *they don't give students enough time*.
It takes a LOT of time to let basics like variables, control flow, encapsulation, etc. to become instinctive knowledge (probably 2 years). But those are just table stakes. Every language has its own paradigm, it's own best practices. Learning those (even in a concentrated mentor environment) can take another two years. Just to become fluent in the language. That's not "mastery" that's "fluency". Fluency is the table stakes of being a professional developer.
Take any .Net language and compare it to T/SQL, for instance. In terms of paradigm you might as well be talking sub-atomic physics vs behavioral psychology. The two approaches are really that different. Yet we expect developers to know and master both.
Oh, and halfway through the project the database gets switched to MariaDB? Yeah, that will end well... Least Common Denominator for the win!
Truth is, most developers or DBAs aren't even fluent in their disciplines of choice. Training is non-existent (or might as well be) because companies don't want to take the time or spend the money.
"Why don't you already know this stuff? We're paying you a fortune and you *don't know this stuff?????!!!!!!*"
Thus spake PHB...
Any classes that the developer or DBA sneak in are quickies and have the same lack of time issue as basic CompSci classes. Sigh.
It also doesn't help the vendors are spewing out new changes, new features, new whiz-bang-golly-gee buzzwords at an ever accelerating rate. Most of which are useless to most developers but excite the clueless. Sigh.
And speaking of management, how can you manage something when you don't know anything about it? Training isn't just for developers you know!
It's enough to make you cry, it really is.
I couldn't have said it better. The thing that irks me, though, are the people that claim to be DBAs or Developers on their resumes, claim to having been one for 10 years, and STILL don't know the basics because they've not invested one iota of time on their own to learn about their trade.
Between the bad schooling, what I consider to be a bad attitude about self improvement and self entitlement, and managers riding/beating on people to get things done quickly rather than correctly, it all makes for a bunch of code zombies that have become a large part of the fabric of this industry.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2017 at 7:51 am
cmick 77911 - Thursday, November 16, 2017 7:19 AMBut how do you know if your code is right or wrong when the examples to learn from don't scale or are not complete? Most articles I find on writing better code never actually explain how or give valid or complete examples that can scale. Some even have code that won't compile for various reasons which is problematic when the reader is trying to learn how to do something they know nothing about.
This is the hard part. I think the way that we sometimes try to teach people is wrong. We have pieces of the puzzle, helping various problems get solved, but not deeply. The democratic publishing of information on blogs, and by sites like this, also contributes, since we are trying to help people get better, but we never know where they are in the journey.
Technology changes so fast, and trying to provide a good roadmap of how to get started in an area is hard. Once you publish incremental learning, plenty of people get left behind, because they don't know the basis and assume that this latest item is the "best" way to get something done.
Most articles/examples aren't complete or scalable, especially for framework stuff. As I've tried to look at EF or other items, too many people assume that the reader knows something already, or they ignore the problematic parts of working with the db in favor or "it's quick and easy". For thousands of projects, that's fine. For the larger applications, that's not true.
I don't have a good solution. Everything I look at often goes down the rabbithole of trying to figure out a way to focus on a problem, while also providing information in a structured format. The Stairways were a start here, but they are hard and long to produce, and we find that these are simple topics, not something like how you add xx feature to your app or database. Books are better, but suffer from similar problems, not to mention that in the middle the author often realizes they should do x instead of y, but if they switch, then the book needs months more to complete.
Open to suggestions here.
November 16, 2017 at 12:48 pm
I am also in the very choir that's being preached to!! 😛
I am a very big believer in doing it right the first time because there never seems to be any time or inclination to doing it over. Way too often the push is to work around issues instead of solving them properly. Quick fixes have an awful tendency of becoming permanent! This is exacerbated in far too many agile environments where everything is boiled down to the current sprint and proper planning is considered unnecessary. or worse, a waste of time.
I am currently working on a project where the database "architecture" was driven by the application development and objected-oriented methodologies were applied to the database resulting in multiple layers of indirection with multiple nested views, numerous scalar functions, procedurally coded triggers and a rat's nest of stored procedures. And they wonder why they have performance issues! 😀
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
November 16, 2017 at 12:53 pm
rat's nest of stored procedures
What do you mean by this? My understanding is that stored procedures are the way to go for DML commands. The business rules properly belong in another layer, but generally these call stored procedures. I do wish SQL Server had a better way to organize them.
November 16, 2017 at 1:01 pm
RonKyle - Thursday, November 16, 2017 12:53 PMrat's nest of stored procedures
What do you mean by this? My understanding is that stored procedures are the way to go for DML commands. The business rules properly belong in another layer, but generally these call stored procedures. I do wish SQL Server had a better way to organize them.
Don't get me wrong, stored procedures should be the primary means of an application's interface to the database. The issue becomes when stored procedures are primarily used to call other stored procedures, when in turn call others, etc. T-SQL is not object-oriented and multiply-nested calls are a hindrance to performance. It's like peeling back the layers of an onion in situations like this. What's effective and preferred in a C# development environment is not true for T-SQL.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
November 16, 2017 at 1:08 pm
RonKyle - Thursday, November 16, 2017 12:53 PM
rat's nest of stored proceduresWhat do you mean by this? My understanding is that stored procedures are the way to go for DML commands. The business rules properly belong in another layer, but generally these call stored procedures. I do wish SQL Server had a better way to organize them.
Don't get me wrong, stored procedures should be the primary means of an application's interface to the database. The issue becomes when stored procedures are primarily used to call other stored procedures, when in turn call others, etc. T-SQL is not object-oriented and multiply-nested calls are a hindrance to performance. It's like peeling back the layers of an onion in situations like this. What's effective and preferred in a C# development environment is not true for T-SQL.
Agreed. Thanks for the clarification. It seemed like you might not have been in favor of stored procedures (something else I've seen).
Viewing 15 posts - 1 through 15 (of 41 total)
You must be logged in to reply to this topic. Login to reply