March 19, 2015 at 8:11 pm
Comments posted to this topic are about the item Common Mistakes
March 19, 2015 at 9:35 pm
According to the interviews that I've done in the last 3 years of Front-End Developers, Database Developers, and DBAs, the biggest mistake made is not knowing what they don't know and the second biggest mistake is not taking the time to find out.
Of course, it's not only the world of Developers that suffer from such a problem. I've run into folks with a Phd in Mathematics that couldn't convert 1416 to Base-10 without a calculator, electricians that think that connecting a ground wire to the shiny spot on a cast iron pipe makes a good ground, doctors that don't know that OTC Naproxen Sodium works just as well as prescription Naproxen Sodium, and dentists that don't know anything about the devastating galvanic effect of dissimilar metals in a wet environment.
I guess that all means that the real mistake is one of attitude.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 20, 2015 at 2:21 am
1) Not understanding the need to separate the logical from the physical. The application is not the database and vice versa. The application places requirements on the database but these are unlikely to be the full set of requirements on the database.
2) NOLOCK - I have previously worked at a multinational that had it as a coding standard requirement (not guidance) on *ALL* SELECT statements. Yes, there is a rather large amount of financial transactions involved. Muppets.
3) Difficut to maintain: terrible code, no/poor documentation and no strategy. Brilliant. [Yes. That is sarcasm.]
EDIT: I couldn't count up to 3!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 20, 2015 at 3:12 am
Sadly I share the experience of seeing more bad coding instead of less the last couple of years, it should be the other way around. What I think contributes to better work is starting a new piece of code with CREATE VIEW instead of CREATE PROCEDURE. Sqlserver as all databases is set-based and procedural code should be avoided as much as possible for lots of reasons. In new work I hardly ever use sp's anymore.
March 20, 2015 at 4:11 am
Not many coming through nowadays at my current gig fortunately, at least not that I understand! It's kind of part of my job to help people do it better so I'd see it as a failure on my part. I help hire most everyone that does back end work, I like to hire people as clever or cleverer than myself (I hope my experience counts for something), so they take hints really quickly, and generally I'm learning from them. It's a nice situation to be in for sure.
March 20, 2015 at 4:50 am
#1 No documentation
Well, someone else can figure out what I meant, can't they?
#2 Incomplete documentation
This code is on a Need-To-Know-Bases and you don't need to know. The rest is obvious so I just write one or two sentences.
#3 Inadequate documentation
Well, this is kind of trivial so I explain a little bit more around it and by the end you will not know what the code does but anything else but what 42 stands for. However this is a shining example of how code should be documented so I lay down all the necessary details without even telling you anything about the actual code. Well, anything but 42.
March 20, 2015 at 5:17 am
Developers who forget the magic words "it depends"
March 20, 2015 at 5:21 am
1. A lack of general understanding about the database.
2. No documentation.
3. A general acceptance of poor performance.
4. The inability or unwillingness to learn new things.
There are others (like loops where they're not needed and inchworm splitters), but they all point back to #1. If people don't understand how the database works, everything goes downhill from there. I guess it stems from attitude.
March 20, 2015 at 5:39 am
Hard coded dates were rampant here.
I 'used to be' a systems analyst at a major pharmaceutical company where there were clear divisions of labor, a set development, test and production environments and rigorous testing and QA requirements, including documentation. I left my SQL/DB2 skills behind over 20 years ago when our eldest was born. I was asked to 'help out' here since I 'knew' SQL and the remote/rural area we now live in has few technical folks. I am painfully aware of my limitations and am studying almost every night and applying what I have learned at every opportunity. The biggest stumbling block has been a complete absence of any documentation at all and hard-coded dates in virtually all view defs. Yes, this past December/January was quite busy!
But, even after such a hiatus, I can still remember what NOT to do - like hard code dates!
Unfortunately, no one else here knows SQL, or any programming tools. So I have no one to learn from or collaborate with. On the plus side, I can set my own (part-time) schedule, I have rediscovered how much I enjoy this and I am considering working towards certification. Just in time for the empty-nest as our youngest will be off at college in 18 months!
March 20, 2015 at 6:09 am
Don't forget the race to the bottom of the payroll scale. Where you had IT majors making good money before, now you have tech school grads and drop outs making min wage. You get less devoted employees and less dedicated professionals. The joy of lowest bidding off-shore contractors adds to the mess.
Why hire one quality developer when you can get several cheapies. The CEO has to make his bonus.
The managers are paid based on head-count, not code quality metrics.
March 20, 2015 at 6:18 am
Using the wrong technical terms ie A "technical" architect who interchanges the term mirroring and replication because they generally do the same thing.
March 20, 2015 at 6:28 am
My favorite is leaving out the USE statement or not using fully qualified object names. Wish I had a nickel for every time some one handed me code and said "just run it".
Unfortunately the first time this happened to me, I was a newby DBA and followed instructions. I then had the misfortune of having to explain why I ran the script against the wrong database (in production!). :blush:
March 20, 2015 at 7:27 am
Novices have no business designing databases, so I won't reiterate all the bad patterns related to that. Instead I'll mention a few observations regarding common mistakes that end users make when coding SQL select statements, which anyone at most any level of an organization can do these days.
#1 Inappropriate use of functions in JOIN or WHERE clause predicates. SQL coders will do things like wrap LTRIM(TRIM( or UDF needlessly around columns in such a way that even a properly indexed table is not leveraged.
#2 Inappropriate use of INNER JOIN versus OUTER JOIN. For example they OUTER JOIN on a required relationship and then filter in WHERE clause, or they INNER JOIN am optional relationship and exclude needed rows from the result.
#3 Inappropriate use of DISTINCT and ORDER BY.
#4 Inappropriate use of inline sub-selects or inline UDF within the SELECT clause.
#5 Inappropriate use of datetime columns. For example SELECT ... WHERE SALESDATE BETWEEN '2015/03/01' AND '2015/03/31'.
#6 Inappropriate use of nullable columns.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 20, 2015 at 7:31 am
robert.mcleod (3/20/2015)
My favorite is leaving out the USE statement or not using fully qualified object names. Wish I had a nickel for every time some one handed me code and said "just run it".Unfortunately the first time this happened to me, I was a newby DBA and followed instructions. I then had the misfortune of having to explain why I ran the script against the wrong database (in production!). :blush:
I guess this is a "it depends" one as I have written scripts that deliberately did not specify the database as it was targetting production but would be run in development and testing environments first and was supposed to do so without change.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 20, 2015 at 7:34 am
While I agree that there are definitely quality issues with software, I don't agree with the assumption below.
We suffer from the chef problem in technology. As more companies look to become software companies, they need to hire more software people. To meet the staffing demand, more and more marginally skilled people will be chosen, and software quality goes down.
In my opinion, the lack of quality (in the USA) is due to a number of factors, but mostly the H1B visa program. Companies bribe politicians to bring in more foreign workers. Those workers are approved because we allegedly don't have sufficient skilled workers. However a lot of the people brought in aren't qualified, and companies pay them far less. This depresses wages overall, leading to less people who want to pursue a career in IT. Companies don't want to pay fair wages, and thus they artificially manipulate the supply of labor.
I believe the second largest cause is the unwillingness to pay for training. The fear that people will leave once they are trained leads a lot of companies to refuse to pay for training. The real cause is non-competitive wages.
I recognize that a lot of companies pay well and train their employees. But we are talking about the market as a whole. Some of the best software comes from companies that are willing to invest. The worst software comes from companies whose only focus is to cut expenses and increase revenue, which is an oxymoron.
The fix to your point above is to increase the supply of quality workers. To do so, you have to pay the cost. If you pay the cost, younger people will be willing to invest in what it takes to succeed. Today, most young people don't want to invest the time and money, knowing it won't pay off in the long run. They can work a low stress job at high pay, or work a high stress job at low pay. Which would you choose?
It comes down to the fact that too many companies aren't willing to invest in a quality work force. Until that is fixed, quality issues won't improve overall.
Dave
Viewing 15 posts - 1 through 15 (of 51 total)
You must be logged in to reply to this topic. Login to reply