March 20, 2015 at 7:37 am
Gary Varga (3/20/2015)
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.
I have seen code like this, where a variable was used to designate the database. If you didn't modify the value, the code wouldn't run at all. The variable would be defined similar to "insert database name here", and I doubt there are (m)any real databases named that way!
Dave
March 20, 2015 at 7:50 am
The funniest issue I have seen is with a major US company that rebuilt their product from scratch, without a test environment. Oh, they thought they had a test environment, but they didn't.
The issue - the software ran fine on an old, low powered, database server, with only one or two other servers to handle all of the services required. They used a 10MB network.
We start implementing the software, in an environment that is specified with more than 15 top of the line servers, on a gigabit network.
Software fails, because the system returns some data faster than expected, and the software is written to expect that particular data last.
- Request data 1, 2, 3, 4 and 5
- (5 comes back first)
- 1 is returned, software then waits for 2, then 3, then 4, lastly 5
- Since 5 came back before the others, and the software doesn't know it received that data, software sits and waits forever - because nobody considered it might come back first, and they didn't have a test environment that would expose the incredibly bad code.
The vendor actually had to come on site to figure out what was wrong. They connected with development, to reproduce it so the developer could debug it. They could reproduce the issue all day long, until they used (a particular brand of remote control software) and that remote control software slowed down the network connection sufficiently to cause the data to be returned in the proper order. After going back and forth enough times, the on site person came to me and explained that our network was too fast.
I particularly enjoyed bringing that issue to our network team.
Dave
March 20, 2015 at 7:56 am
swwg69 (3/20/2015)
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.
Head count and whether their total payroll expense is under some arbitrary budget number.
Why should we pay X for this employee, when applicant Y is willing to make half as much? They both know how to spell SQL.
Dave
March 20, 2015 at 8:20 am
What exactly is the "chef problem"? A quick Google search didn't turn up anything seemingly relevant. Or perhaps Steve meant "chief"?
March 20, 2015 at 8:27 am
I blame management, almost entirely. They can stifle the most talented programmer, enable the most incompetent programmer, and prevent junior programmers from ever realizing their potential. You cannot train your way out of bad management.
- Reinvention of the wheel, in terms of best practices and project management. Many companies believe they exist in a technical vacuum and ignore industry-wide best practices and project management techniques. Why is waterfall development still practiced? Don't we know better by now? And how about HealthCare.gov? Didn't we all know it was going to fail initially? It had to, given that a complete system involving multiple insurance companies and multiple government agencies was required to go from never-turned-on to fully-available-to-the-public-with-all-features with a hard deadline, and the whole project was managed by the government. Seriously, who thought this was going to work?? Don't we, as the programmer community, know better by now?
- Inefficient corporate training and mentoring. Most junior programmers arrive at their first job completely unprepared for real-life programming. They don't know how to approach an existing system in which numerous people of varying competence are working and get something done in there. They also expect that there are easy answers to their questions. Sometimes, there are answers if you look... conflicting answers, outdated answers, partial answers, wrong answers, non-answers. It's not school. Training does not address these mindsets. It's not fun for the juniors to enter the real world, and some of them complain bitterly (to HR) that their job shouldn't be this hard.
- HR's failure to interview candidates correctly and their later failure to admit they made a mistake in hiring and quickly correct it. The best developers should be involved in interviewing. I'm often stunned when a new programmer is hired without any input from the developers who will be working with him/her. During the dot-com boom, a company I was with somehow hired a programmer who spoke almost no English and didn't seem to have any programming skills either (though it was hard to tell since no one could explain anything to him). They hung onto him for almost a year before letting him go. He was completely useless in that job. It was really cruel to have hired him for something he couldn't do, let him sit at a desk for a year, then fire him like it was his fault.
- Short-sighted project management refusing to address technical debt and building more of it. I've been on projects where the end-result is a big mess because of all the changing requirements over the length of the project, yet developers are forbidden from taking the time to clean it up, undo the parts that ended up not being used, rename things to what they ended up being called, etc. The resulting code looks a mess and is only intelligible to those who remember the "history" of it. Documentation? Forget it, the project already went over schedule and budget (of course it did, the project was waterfall, why was the schedule overrun a surprise?)
- Management dividing programmers into divisions that don't speak to each other, don't share knowledge, duplicate systems, use different terminology for the same thing, use different development processes, and refuse to do work because it doesn't "belong" to them. The only thing these groups share freely is blame. This is entirely a management problem, no matter how much developers fight against it or buy into it.
March 20, 2015 at 8:50 am
CGMChris (3/20/2015)
What exactly is the "chef problem"? A quick Google search didn't turn up anything seemingly relevant. Or perhaps Steve meant "chief"?
It's the kind of problem that they bring in Gordon Ramsey to fix, though I think if I saw him coming I'd burn down the building, change my name, and move to Bolivia.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
March 20, 2015 at 8:59 am
My current job title is Project Manager. I don't normally write code but I've found lately I've had to get more involved in it (I had to write an entire application in one contract) because of a couple things:
1) Companies are trying to do more with fewer people. If I need some DB extracts for project planning, I can't wait two weeks while they find someone with enough cycles. I step in and do them myself.
2) The quality of many DBAs/Programmers just isn't there.
3) The volume of data that is being generated/captured
My background is application development. Going back to mainframe/COBOL days. Back then, it was paramount that you minimized bad data going into the database. Now, organizations seem rely on various data quality tools to find the errors after the fact.
March 20, 2015 at 9:04 am
Stephanie Giovannini (3/20/2015)
I blame management, almost entirely. They can stifle the most talented programmer, enable the most incompetent programmer, and prevent junior programmers from ever realizing their potential. You cannot train your way out of bad management.- Reinvention of the wheel, in terms of best practices and project management. Many companies believe they exist in a technical vacuum and ignore industry-wide best practices and project management techniques. Why is waterfall development still practiced? Don't we know better by now? And how about HealthCare.gov? Didn't we all know it was going to fail initially? It had to, given that a complete system involving multiple insurance companies and multiple government agencies was required to go from never-turned-on to fully-available-to-the-public-with-all-features with a hard deadline, and the whole project was managed by the government. Seriously, who thought this was going to work?? Don't we, as the programmer community, know better by now?
- Inefficient corporate training and mentoring. Most junior programmers arrive at their first job completely unprepared for real-life programming. They don't know how to approach an existing system in which numerous people of varying competence are working and get something done in there. They also expect that there are easy answers to their questions. Sometimes, there are answers if you look... conflicting answers, outdated answers, partial answers, wrong answers, non-answers. It's not school. Training does not address these mindsets. It's not fun for the juniors to enter the real world, and some of them complain bitterly (to HR) that their job shouldn't be this hard.
- HR's failure to interview candidates correctly and their later failure to admit they made a mistake in hiring and quickly correct it. The best developers should be involved in interviewing. I'm often stunned when a new programmer is hired without any input from the developers who will be working with him/her. During the dot-com boom, a company I was with somehow hired a programmer who spoke almost no English and didn't seem to have any programming skills either (though it was hard to tell since no one could explain anything to him). They hung onto him for almost a year before letting him go. He was completely useless in that job. It was really cruel to have hired him for something he couldn't do, let him sit at a desk for a year, then fire him like it was his fault.
- Short-sighted project management refusing to address technical debt and building more of it. I've been on projects where the end-result is a big mess because of all the changing requirements over the length of the project, yet developers are forbidden from taking the time to clean it up, undo the parts that ended up not being used, rename things to what they ended up being called, etc. The resulting code looks a mess and is only intelligible to those who remember the "history" of it. Documentation? Forget it, the project already went over schedule and budget (of course it did, the project was waterfall, why was the schedule overrun a surprise?)
- Management dividing programmers into divisions that don't speak to each other, don't share knowledge, duplicate systems, use different terminology for the same thing, use different development processes, and refuse to do work because it doesn't "belong" to them. The only thing these groups share freely is blame. This is entirely a management problem, no matter how much developers fight against it or buy into it.
Wow, I would love to say that I haven't seen anything like what you described. The problem is, I have witnessed all of that and more. One additional example is hiring a technical person whose sole skill was with applications we didn't use, in a Unix environment (we were almost entirely Windows at the time), and who had never used Windows whatsoever. This person couldn't even copy a file in Windows. When I suggested sending them to internal training that we offer to end users on exactly that topic, I was told that management would never approve it, as it would make the hiring manager look bad.
Dave
March 20, 2015 at 9:09 am
Stephanie Giovannini (3/20/2015)
- Reinvention of the wheel.- Inefficient corporate training and mentoring.
- HR's failure to interview candidates correctly.
- Short-sighted project management refusing to address technical debt and building more of it.
- Management dividing programmers into divisions.
Wow. +1 million. I haven't seen you around the office, but it sure sounds like you're here somewhere. 😉
Seriously, I think these problems are far more common than any of us would like to believe. That's a great summary. The HR issue is the only one I'd revise. The HR people work in HR. We need competent technical people doing interviews. This may or may not be a senior I.T. person, but what matters is competency in assessing others.
It all points to competency at one level or another.
March 20, 2015 at 9:39 am
Jeff Moden (3/19/2015)
I've run into folks with a Phd in Mathematics that couldn't convert 1416 to Base-10 without a calculator,
Reminds me of watching my son's Knowledge Bowl competition this week. One of the questions was "convert BED from hex to decimal". The three teams all had guesses < 1000. Of course, they have 15s to answer, and the third team (of three) ended up with about a minute, but they weren't sure how to convert.
I know it was around 3,000 pretty quickly, but couldn't quite do the math in my head in 15s.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 20, 2015 at 9:40 am
BTW, I see lots of generalizations. I was hoping for specifics. Not every one but a specific example of a common mistake. Perhaps like using NOLOCK everywhere or *= in code but forgetting a join condition.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 20, 2015 at 9:45 am
CGMChris (3/20/2015)
What exactly is the "chef problem"? A quick Google search didn't turn up anything seemingly relevant. Or perhaps Steve meant "chief"?
The chef problem is this:
I'm a great chef (not really, but imagine). I open a restaurant that's really successful. I decide to expand and open a second restaurant. I can't cook at both, so I hire a top notch graduate of a culinary school, or pull him from another restaurant. He/she does well, but not as well as me. He's/She' not me.
We continue expanding, and each time we hire a chef, he or she is a little less talented, because being a chef is not cooking, and it's not as simple as following recipes. Eventually my restaurants are Chiptole or McDonalds, not Chez Alice.
I see the same thing in technology, where we hire some great workers, but at some point we are hiring people that just don't have great skills. This is mostly true from my corporate experience. Startups tend to get more "chefs" than cooks.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 20, 2015 at 9:46 am
Having spent 20+ years as a software engineer programming in 10 different, 2nd through 5th generation, software languages, I have a good understanding of the paradigm differences between computer software and database software (SQL), and the relative mindsets of the people writing said software. The 2 sets of languages have completely different paradigms as the basis for their implementations and executions.
I could identify a long list of problems/common mistakes but even the fundamental problems come down to this one problem:
"Assuming that modern computer hardware and components are so fast that taking the extra effort to write efficient code is not necessary."
If the delivered data is correct, then the only possible issue left is performance, and that means speed.
Most of the performance problems I have seen in my career as a DBA pertain to performance. Even blocking problems have, as their root cause, speed (of execution).
Compared to most computer software languages, SQL is a quirky language with:
> many syntax rules,
> hidden performance rules.
To ensure good query performance, companies should invest a little time in training their development staff members to know at least some of the basic rules for coding efficient SQL.
March 20, 2015 at 10:24 am
The most common mistake I've seen in SQL Server development is really only partially the developers fault. Many places I've been to (even some software houses) hire developers who are .Net developers, and expect them to also do the database development, without any consideration or training. They tend to not think in sets, and try to beat the database into submission with how they view the world from a procedural, functional, or object perspective. Just because you can write a SELECT statement doesn't mean you know how to do database programming.
March 20, 2015 at 12:17 pm
Steve Jones - SSC Editor (3/20/2015)
CGMChris (3/20/2015)
What exactly is the "chef problem"? A quick Google search didn't turn up anything seemingly relevant. Or perhaps Steve meant "chief"?The chef problem is this:
I'm a great chef (not really, but imagine). I open a restaurant that's really successful. I decide to expand and open a second restaurant. I can't cook at both, so I hire a top notch graduate of a culinary school, or pull him from another restaurant. He/she does well, but not as well as me. He's/She' not me.
We continue expanding, and each time we hire a chef, he or she is a little less talented, because being a chef is not cooking, and it's not as simple as following recipes. Eventually my restaurants are Chiptole or McDonalds, not Chez Alice.
I see the same thing in technology, where we hire some great workers, but at some point we are hiring people that just don't have great skills. This is mostly true from my corporate experience. Startups tend to get more "chefs" than cooks.
This is why every IT development team needs a senior level team leader; both present on site and engaged in the development process. Not a project lead, but a technical person who's been there and done that. They need someone who can establish patterns and practices and then sniff the code. It's no different from sports teams, music bands, or restraunt kitchens. Excluding rare exceptions like 'The Smashing Pumpkins' and Facebook, we just can't expect a team of freshers who only learned how to use the toolset last year to pull off a successful project.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 16 through 30 (of 51 total)
You must be logged in to reply to this topic. Login to reply