January 23, 2012 at 10:17 am
L' Eomot Inversé (1/23/2012)
When is something "jiggling" (bad practise) rather than "experimentation" (an essential component of research)?
I think it's a general attitude. One is, "Let's see if I can figure out how this works." The other is, "If I change this char(4) to a char(100) it works, I don't know why but ship it anyway," without doing research into why a char(100) is needed. It very well could be malformed data is causing the error. In the discussion Steve linked to a developer redid an allocation algorithm and changed a number from 0xa0000000 (which didn't work) to 0x80000000 (which did work) and couldn't explain why it worked. It gets more complicated than that but that's a summary.
L' Eomot Inversé (1/23/2012)
And perhaps it's worth pointing out that understanding how and why something works is sometimes utterly unimportant. For example in France I can safely use the expression "un coup de Jarnac" because I know what it means and so does pretty much everyone else; I don't need to know why it means that...
And since it's been used that way for centuries it would fall under, "years and years of...testing":
Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work.
If you can't understand it, a lot more testing is needed than if you do understand it.
January 23, 2012 at 11:31 am
Steve Jones - SSC Editor (1/23/2012)
Gus,I wouldn't call experimenting "jiggling". Now if you try things and then slip that code into a deployment without understanding it, which implies incomplete testing (how can you write tests if you don't understand what to break?), that's jiggling.
To borrow a phrase we've started using around here - jiggly code is most often based on squishy requirements. Squishy requirements are those 50K foot view requirements with no chance at a quantifiable, provable output: they give you the general direction the weind is blowing in, but not what to do when the wind doesn't blow one day.
That unfortunately is eactly how "jiggly code" end up in production. If you don't know what your success criteria are, the QA phase devolves into a glorified smoke test (I didn't get an error, so it MUST be ok).
So developers and DBA's are on the hook for not spitting out solutions they don't understand, but it is imperative to remember that they're the end of a long food chain, each party being responsible for their own contribution to the jiggle.
----------------------------------------------------------------------------------
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?
January 23, 2012 at 12:38 pm
I see this practice more often than I would like. Code that is untested and released to prod. Or different code released to prod than what was released to QA. Then things are jiggled until it is working again. It just becomes a headache.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 23, 2012 at 12:50 pm
Matt Miller (#4) (1/23/2012)
So developers and DBA's are on the hook for not spitting out solutions they don't understand, but it is imperative to remember that they're the end of a long food chain, each party being responsible for their own contribution to the jiggle.
They shouldn't be on the end of the food chain, but if they are that is the problem. A DBA should be involved on the front end ... providing consultation or even writing the specifications. He should have direct access to the requirements document and that document should be fully developed before a single line of code is written.
If people are writing code or designing databases without a specification or requirements document they are part of the problem.
The probability of survival is inversely proportional to the angle of arrival.
January 23, 2012 at 1:04 pm
sturner (1/23/2012)
Matt Miller (#4) (1/23/2012)
So developers and DBA's are on the hook for not spitting out solutions they don't understand, but it is imperative to remember that they're the end of a long food chain, each party being responsible for their own contribution to the jiggle.They shouldn't be on the end of the food chain, but if they are that is the problem. A DBA should be involved on the front end ... providing consultation or even writing the specifications. He should have direct access to the requirements document and that document should be fully developed before a single line of code is written.
If people are writing code or designing databases without a specification or requirements document they are part of the problem.
Agreed that is how it SHOULD be. That said, the cynic in me can't help but point out that "in theory, theory and practice are the same - in practice, not so much...." Meaning - I know I personally have seen occasions where you just are not allowed to do the right thing, no matter how irrational the reasoning is for doing it the wrong way.
So - just because said jiggly code makes it into production doesn't mean I wanted it to.
----------------------------------------------------------------------------------
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?
January 23, 2012 at 2:00 pm
When initially writing a block of SQL code, I often times jiggle it around a number of times until I get just the right join and optimal execution plan.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 24, 2012 at 4:50 am
Matt Miller (#4) (1/23/2012)
sturner (1/23/2012)
Matt Miller (#4) (1/23/2012)
So developers and DBA's are on the hook for not spitting out solutions they don't understand, but it is imperative to remember that they're the end of a long food chain, each party being responsible for their own contribution to the jiggle.They shouldn't be on the end of the food chain, but if they are that is the problem. A DBA should be involved on the front end ... providing consultation or even writing the specifications. He should have direct access to the requirements document and that document should be fully developed before a single line of code is written.
If people are writing code or designing databases without a specification or requirements document they are part of the problem.
Agreed that is how it SHOULD be. That said, the cynic in me can't help but point out that "in theory, theory and practice are the same - in practice, not so much...." Meaning - I know I personally have seen occasions where you just are not allowed to do the right thing, no matter how irrational the reasoning is for doing it the wrong way.
So - just because said jiggly code makes it into production doesn't mean I wanted it to.
Yeah no kidding. The original kernel thread had the BOSS complaining about people jiggling code. That makes a pretty big difference right there.
January 24, 2012 at 9:29 am
patrickmcginnis59 (1/24/2012)
Yeah no kidding. The original kernel thread had the BOSS complaining about people jiggling code. That makes a pretty big difference right there.
True - but I doubt that Linus Torvald could be classified as the typical boss: he's also talking as the cheif architect and lead developer. The point that he (and Steve) are both attempting to make is - know WHY you're doing something, and know WHAT you're changing.
I obviously don't know what you've experienced in this area - but this state of mind affects all tiers within our groups. The "rush in and just fix it" approach has been eroding at best practices for years, and Linus is just pointing out the latest iteration of said corruption in his downline. That said - whether it starts with the boss firing a directive to "just do it" or if the devs can get away with sloppy problem identification, doesn't really matter in the long run: the sloppy code still gets through.
The only way to get rid of this is to draw a line in the sand as an organization, stating that it is cheaper in the long run to do it the right way than to do it multiple times the wrong way. You certainly need dev support for that, but dev support alone doesn't do much is mgmt isn't on board as well. Your process has to bear this out as well.
----------------------------------------------------------------------------------
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?
February 1, 2012 at 8:49 am
Eric M Russell (1/23/2012)
When initially writing a block of SQL code, I often times jiggle it around a number of times until I get just the right join and optimal execution plan.
Agree with you on this. I normally write code to get it to do what I want. Then I re-write it to do it "properly".
-------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply