August 20, 2015 at 1:43 pm
ZZartin (8/20/2015)
Eric M Russell (8/20/2015)
Jeff Moden (8/20/2015)
Iwas Bornready (8/20/2015)
I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.
They just need to prove it's fixed in development and QA first, before submitting it for production.
As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛
I've not seen my developers be "random" about what they choose to improve. Normally it's well thought out and will either make the system work better / faster / stronger or will save us time in future maintenance. I will note these developers are very familiar with the systems they are working on, and were involved in the design process (a la Agile) as well as the coding.
On the topic of mistakes made, I think our culture in the USA has been to highlight mistakes in a way that is counter-productive. We see them as "negative" - i.e. you made a mistake so you must not know what you are doing so now we will insult your intelligence. In my experience, it's better to "teach it through" and celebrate the lesson learned. And yes, I do prefer that those lessons happen in the TEST or QA systems!
You can't learn new things without making some mistakes. The trick is to manage the mistakes so they cause the least possible harm. Developer sandboxes for techs, cadavers for medical, and training software for both.
Now for the joke of the day:
A doctor took his Harley Davidson motorcycle in to the mechanic for an overhaul. The mechanic pulled the heads, ground the valves, replaced worn parts, checked tires, rims, spokes, put in a new air cleaner - well, you get the idea. As he worked, he thought to himself "this isn't so different from what that doctor does".
When the doctor came to pick up his motorcycle, the mechanic said, "hey Doc, I do pretty much the same thing as you. On a motorcycle, the engine is the heart, intake and exhaust is like respiration, everything has a related body function. So how come you get paid so much more than I do?"
The doctor replied: "Try doing it with the engine running."
Steph Brown
August 20, 2015 at 1:49 pm
ZZartin (8/20/2015)
Eric M Russell (8/20/2015)
Jeff Moden (8/20/2015)
Iwas Bornready (8/20/2015)
I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.
They just need to prove it's fixed in development and QA first, before submitting it for production.
As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛
Then query the top 10 worst performing statements, and let them chew on that.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 20, 2015 at 2:50 pm
ZZartin (8/20/2015)
As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛
I don't. I'm all for programmers looking to scratch an itch, fix something that hasn't been a priority. I want programmers that look for things.
They need to finish what work they are assigned, but I also don't want to assign them 100% of the time to a project. That's a burnout and poor management practice
August 20, 2015 at 3:00 pm
Eric M Russell (8/20/2015)
ZZartin (8/20/2015)
Eric M Russell (8/20/2015)
Jeff Moden (8/20/2015)
Iwas Bornready (8/20/2015)
I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.
They just need to prove it's fixed in development and QA first, before submitting it for production.
As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛
Then query the top 10 worst performing statements, and let them chew on that.
To make it fun, have a contest to see which developer can write the most efficient version of the query.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 20, 2015 at 5:52 pm
Jeff Moden (8/19/2015)
One of my previous bosses said that "If you don't make mistakes, I'm not pushing you hard enough".
That's probably correct for people past a certain level of competence and a certain amount of experience and probably for green trainees, but there's a stage in between where pushing people hard enough to have them make mistakes can wreck their self-confidence.
While I agree with that, the place to experiment and make mistakes is on the Dev box, not the Prod box.
Yes, of course. But unless your Desk checking, Code Reviews,Unit testing, QA/QC, Verification, and Release Control can catch all those mistakes before any of them hit production either you are lucky or you have a Verification budget that would amaze most people not working on software where bugs have a very high risk of killing people. So you dealing with mistakes in production is something most people will need to do.
Folks should also buy a copy of the Developers Edition and spend a little time solving problems they find on forums or experimenting with new things. In other words, they should spend some time practicing their trade so they don't find so many bumps in the road. Doctors read about new things after hours and attend seminars on their own time. Pianists practice every day. Athletes practice on a regular basis. Why do people consider the job of being a DBA or Developer any different?
Probably because they think developers and DBAs deserve to get paid at what to the average working man is a fantastic rate just for putting in a 9 to 5 day five days a week with 48 mins off for lunch and never do anything work related outside of those 36 hours each week unless they get paid for it.
Actually one of the things I like about SQLServerCentral is that a lot of people here don't think like that, but I've obeserved over the years that a lot of people do.
The time to make mistakes is during practice... not when it counts. Mistakes when it counts should really piss you off at yourself.
I disagree. Mistakes when it counts are inevitable without that unlimited veification budget. Even with that unlimited budget you can never be certain that nothing gets through. Sometimes a bit of software get into production on thousands of machines, is an important part of allowing the machine to communicate with human beings, is invoked many times a minute on each machine, and lasts for more than a year before manifesting problems on just some of the machines, and when the problems do manifest people spend enormous amounts of time trying to find a bug and end up replacing that bit of software with something new instead of just fixing a bug because they never manage to find out why the original software sometimes doesn't work.
Tom
August 20, 2015 at 6:16 pm
I'll admit that there are mistakes that make it through to production where I work but they are very few, far between, and usually nearly trivial in nature because we have all of what you point out in place. The thing is, it doesn't cost as much to do as you would think and, compared to how it was when I first got there, is a drop in the bucket compared to the massive amounts of rework they were having to do just to keep the systems from swallowing themselves. It was like the proverbial too small hot water heater where if someone turn water on in the kitchen sink, the person taking a shower would freeze. And there were a huge number of toilet flushes every day. You can imagine how well those went. Systems freezing for 10 minutes at a time was not a good thing at all.
For those that don't have the budget for any kind of quality/performance testing, let me tell you that you're paying out the nose in one form or another. Spend some money on the things that Tom mentioned. It's well worth it.
Shifting gears, if your DBAs are 9-5'rs and nothing more, then they're either unimaginably good or you need to find some that actually are. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 21, 2015 at 3:06 am
Stephanie J Brown (8/20/2015)
ZZartin (8/20/2015)
Eric M Russell (8/20/2015)
Jeff Moden (8/20/2015)
Iwas Bornready (8/20/2015)
I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.
They just need to prove it's fixed in development and QA first, before submitting it for production.
As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛
I've not seen my developers be "random" about what they choose to improve. Normally it's well thought out and will either make the system work better / faster / stronger or will save us time in future maintenance. I will note these developers are very familiar with the systems they are working on, and were involved in the design process (a la Agile) as well as the coding.
On the topic of mistakes made, I think our culture in the USA has been to highlight mistakes in a way that is counter-productive. We see them as "negative" - i.e. you made a mistake so you must not know what you are doing so now we will insult your intelligence. In my experience, it's better to "teach it through" and celebrate the lesson learned. And yes, I do prefer that those lessons happen in the TEST or QA systems!
You can't learn new things without making some mistakes. The trick is to manage the mistakes so they cause the least possible harm. Developer sandboxes for techs, cadavers for medical, and training software for both.
Now for the joke of the day:
A doctor took his Harley Davidson motorcycle in to the mechanic for an overhaul. The mechanic pulled the heads, ground the valves, replaced worn parts, checked tires, rims, spokes, put in a new air cleaner - well, you get the idea. As he worked, he thought to himself "this isn't so different from what that doctor does".
When the doctor came to pick up his motorcycle, the mechanic said, "hey Doc, I do pretty much the same thing as you. On a motorcycle, the engine is the heart, intake and exhaust is like respiration, everything has a related body function. So how come you get paid so much more than I do?"
The doctor replied: "Try doing it with the engine running."
I like it, nice.
Obviously you don't want developers randomly picking things to improve. For me I do find there are always odd days where someone is between bits of project work and can't really embark on anything significant, and so it's useful to have in your head non-optimal if not absolutely critical things that you want to improve if possible. I store these up as a list of nice to haves and discuss them to see if the ideas generate enthusiasm for tidying, on the old boy scout principle of leaving things tidier than you found them.
August 21, 2015 at 3:21 am
podmate (8/20/2015)
I have never worked for a tech employer that would pay you for training or encouraged you to train on company time (barring being sent offsite for training which was VERY rare).
I'll gloat a little. My company does. A lot of the devs don't take advantage of what's on offer, but it is there.
Yes, companies doing that is rare, they do exist though.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 21, 2015 at 7:43 am
GilaMonster (8/21/2015)
podmate (8/20/2015)
I have never worked for a tech employer that would pay you for training or encouraged you to train on company time (barring being sent offsite for training which was VERY rare).I'll gloat a little. My company does. A lot of the devs don't take advantage of what's on offer, but it is there.
Yes, companies doing that is rare, they do exist though.
The company I've been working for does have some budget for training, maybe a few thousand dollars yearly to spread between a team of twenty, but it's not enough for everyone to attend formalized offsite training. Actually, I've never requested training for myself, other than reimbursement for a couple of certification books, and one time I attended a day conference delivered by Adam Machanic, which was well worth the $150. On a slow day, I'll self study, maybe read a white paper or install the latest SQL Server CTP on my desktop and start up a side project that I'll context switch to when time allows.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 21, 2015 at 9:55 am
This is why I am pushing unit testing. The things that Tom mentions are true. We don't have huge verification budgets, nor time, and mistakes will be made. However if you start to write tests for those mistakes, you can catch them in the future, prevent regressions, and learn from your mistakes. Sometimes writing a test can help teach you what pattern you're doing poorly.
And no, I don't expect all tests to be written first, nor 100% code coverage. Testing the things you do well is silly. However testing for the things you don't do well, the mistakes you make, and growing your test skills over time, is a good practice. It's also cheap and easy, with tests automated and running for each deployment.
These tests do tend to catch the trivial mistakes you make as a developer.
August 21, 2015 at 10:05 am
Steve Jones - SSC Editor (8/21/2015)
This is why I am pushing unit testing. The things that Tom mentions are true. We don't have huge verification budgets, nor time, and mistakes will be made. However if you start to write tests for those mistakes, you can catch them in the future, prevent regressions, and learn from your mistakes. Sometimes writing a test can help teach you what pattern you're doing poorly.And no, I don't expect all tests to be written first, nor 100% code coverage. Testing the things you do well is silly. However testing for the things you don't do well, the mistakes you make, and growing your test skills over time, is a good practice. It's also cheap and easy, with tests automated and running for each deployment.
These tests do tend to catch the trivial mistakes you make as a developer.
Heh... who tests the unit test code to make sure that's right? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 21, 2015 at 10:13 am
podmate (8/20/2015)
There is a big difference between medical practice and being a technologist.
Sorry, this hits a vein.
I'd agree - but you can sometime run into similar concerns and responsibilities. For one - having worked as a technologist supporting medical practice, there were some very real cases where a screwup on our end could have drastic consequences. Among other thing - our little practice was in charge of the system routing results and medication requests to and from the clinical units in a hospitals: getting those screwed up wasn't an option, since that could very easily lead to injury or worse.
We only had one instance where something went really sideways during that time, but let's just say that when it did - no one slept until BOTH the technical issue AND the "real-life" consequences were resolved. I will say - that's not a feeling I would ever forget.
I think there's a real disease in thinking that our screw-ups don't have very real consequences or can be tolerated, and that only the person with the scalpel holds the responsibility. People CAN get hurt by our actions, so tolerating poor quality just isn't an option for me anymore. Even though I am not in healthcare It anymore , it's a lesson I took with me.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 21, 2015 at 2:37 pm
GilaMonster (8/21/2015)
podmate (8/20/2015)
I have never worked for a tech employer that would pay you for training or encouraged you to train on company time (barring being sent offsite for training which was VERY rare).I'll gloat a little. My company does. A lot of the devs don't take advantage of what's on offer, but it is there.
Yes, companies doing that is rare, they do exist though.
I guess I can gloat too. For about 80% of my time working in computing my employer has either provided in-house training, or provided out-of-house-training (usually short courses at Universities), or encouraged using company time for training or learning, or paid for attendance at conferences, or paid for access to documentation providers so that I could get copies of any scirntific papers, university research reports, or PhD theses that I wnted to read, or payed for membership of a learned society and provided time off for attending its events. More that 50% of the time was with employers who did all of those things.
Tom
August 21, 2015 at 5:06 pm
Steve Jones - SSC Editor (8/21/2015)
We don't have huge verification budgets, nor time, and mistakes will be made. However if you start to write tests for those mistakes, you can catch them in the future, prevent regressions, and learn from your mistakes. Sometimes writing a test can help teach you what pattern you're doing poorly.
I agree totally - writing tests to detect repeats of previous mistakes can both help you understand those mistakes better, which makes you less likely to make them again, and (if you have each unit test roll forward as long as the requirement it checks is valid) ensure that anyone responsible for maintenance and/or enhancement of the code in the future who makes a similar mistake will be able to discover it quickly.
And no, I don't expect all tests to be written first, nor 100% code coverage. Testing the things you do well is silly. However testing for the things you don't do well, the mistakes you make, and growing your test skills over time, is a good practice. It's also cheap and easy, with tests automated and running for each deployment.
I think it's sometimes useful to write at least some of the tests first, because agreeing what a test should do with the various interested parties can improve your understanding of what is actually required in the unit for which the test is applicable, and actually turning that agreement into a script and code to implement that test can make you spot holes in the agreed description of what's required. I still haven't decided whether I think completely test driven development is always a good thing (although it's something I'd already been discussing with colleagues for at least a couple of decades before someone coined a name for it and announced it as a wonderful panacea).
I also believe that testing the things I do well is essential - for example just because the first two hash functions I wrote met all their requirements I didn't assume that the third one would, and the unit tests demonstrated that it didn't (even today, when one normally picks a hash function of the shelf rather than making a new one, I've seen people get the wrapper wrong).
The rest I agree with 100%.
Tom
August 24, 2015 at 10:50 am
Jeff Moden (8/21/2015)
Heh... who tests the unit test code to make sure that's right? 😉
The developer, other developers, whoever. If it's not, change it. Tests aren't, nor should they be immutable. Nor should they even always be used. If it's a bad test, as the team determines, throw it away.
Don't get silly with saying who checks the checkers that check the workers. Who tests your code? How do you know it's right? However you determine it's right, that's a test. I'm saying automate that, don't expect that developers will always run that check when they change code.
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply