January 23, 2012 at 12:06 am
Comments posted to this topic are about the item Jiggly Code
January 23, 2012 at 2:51 am
I am always amazed when people (a minority - I hope!!!) post on forum (it happens here) looking for a script to use in production. From the way some of these discussions go they just want the solution. If it doesn't work the way they want it to then they complain to the person who supplied the script even if that person (generously) resolved 90% of their task. It is these people I worry about. They are either under too much pressure or are not professional enough to ensure that they know what they are doing.
You have a task and what to know how to do it? Research it. What a hint for a starting point? Feel free to ask as its the smart thing to do (if you cannot find a reasonable starting point yourself). Stuck achieving a particular step? Again, have a search and if you cannot find the solution then ask once more.
It is essential that you understand what you deliver otherwise you cannot support it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 23, 2012 at 6:29 am
I have to admit, I'm sometimes guilty of "jiggling the code till it unbreaks".
I've had to do that in order to teach myself what little I know of XQuery for example. The documentation is abysmal, the online tutorials I've found are shallower than dew on a lawn, and I've had to "try things till it works" more than a few times. So, I have a lot of excuses, and have my practice of this well-justified and thoroughly rationalized (yes, I'm laughing at myself as I type that), but I haven't found a better solution in that case.
At the same time, I'm enough of a hypocrite that I agree completely with Linus on this one, even while I break the rule myself.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 23, 2012 at 6:33 am
GSquared (1/23/2012)
I have to admit, I'm sometimes guilty of "jiggling the code till it unbreaks".I've had to do that in order to teach myself what little I know of XQuery for example. The documentation is abysmal, the online tutorials I've found are shallower than dew on a lawn, and I've had to "try things till it works" more than a few times. So, I have a lot of excuses, and have my practice of this well-justified and thoroughly rationalized (yes, I'm laughing at myself as I type that), but I haven't found a better solution in that case.
At the same time, I'm enough of a hypocrite that I agree completely with Linus on this one, even while I break the rule myself.
I think I know you better than that. For example, you've probably done enough experimentation with XQuery to be able to explain both cause and effect to someone else. I would't put that in the "Jiggling the Code" category. I'd put that in the "well done research" category.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2012 at 6:39 am
I think the problem isn't so much the direct fault of the people doing the work. I think it's the culture that has been developed over the years and a lot of people have been sucked in by that culture.
As Steve implied, developers are usually under a lot of pressure to just "get the job done" and "get it off their plates". They've not necessarily been trained to think down the road nor are they being paid to do so. In fact, a lot of managers will kill the proverbial messenger of bad news. Their managers just want to hit that magic milestone and the managers frequently aren't aware of what's in or not in the code. To wit, neither the developers nor the managers know what they don't know.
Unfortunately, that costs a lot of companies a lot of money in panic rework and a loss of customers due to what appears to be shoddy work.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2012 at 7:09 am
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.
January 23, 2012 at 7:28 am
Agreed with all. Sometimes you have to research through experimentation but the key difference is the output of any such experimentation:
Output: Knowledge - This is research and is a invaluable way to learn at times.
Output: Production code - this is jiggling and is a dangerous tactic.
Obviously jiggling have the same results as applying knowledge to the creation of production code if it works but if it doesn't work then you are no closer to a resolution but now you have pushed the issue into production.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 23, 2012 at 7:37 am
developers are usually under a lot of pressure to just "get the job done" and "get it off their plates"
This is a very elegant analogy for what takes place some times. I've had similar conversations with many other developers and often it really comes down to demands and not programming style. "Code Jiggling" as it were, I think is an issue because it's a gamble, and sometimes it does actually work for a quick fix, which might lull the developer into a false sense of security, and encourage them to do it again, and again, and possibly not under a time crunch.
Overall though, I think it's more a symptom of a wider spread issue, because whenever jiggled code breaks again, the next developer to work on it has arguably a harder problem then the person who wrote it in the first place, and this can cascade through generations of code revision. Developers need to be aware of these bad habits and strive to avoid them whenever humanly possible, but organizations should put forth efforts to encourage proper devotion to best coding practices and timelines to avert those situations before they happen.
January 23, 2012 at 8:06 am
When is something "jiggling" (bad practise) rather than "experimentation" (an essential component of research)? When I'm learning something new, I play with it to see what causes have what effects; most things in computing are abominably badly documented, sometimes so badly and opaquely that I can't see any point in trying to make sense of the documentation.
If I am trying to tune complex queries I will try things and measure the results; in my view anyone who thinks they don't need to do that is either wrong or have achieved a level of knowledge and understanding of the optimiser and data engine that is beyond the capacity of most ordinary mortals (a lot more often the former than the latter). Having got some results I will make sure I understand why they are what they are before I choose a version to put into production. I guess it's that "understanding" step that makes the difference between good and bad practise. But the stuff before that step, the experimentation and measurement, appears to be jiggling, so surely jiggling is only bad practise when it's done blindly and with no intention of reaching any understanding of what's happening?
Anyway, I shall conmtinue happily to "jiggle" to my heart's content as an essential part of my favourite pass-time: learning new things.
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 (after all, hardly anyone cares who did what in 1547, nor what it was that the Jesuits claimed he had done in their Dictionnaire de Trévoux which they published a couple of centuries later; even fewer know; but that doesn't stop people from using and understanding the phrase).
Tom
January 23, 2012 at 8:27 am
L' Eomot Inversé (1/23/2012)
When is something "jiggling" (bad practise) rather than "experimentation" (an essential component of research)? When I'm learning something new, I play with it to see what causes have what effects; most things in computing are abominably badly documented, sometimes so badly and opaquely that I can't see any point in trying to make sense of the documentation.If I am trying to tune complex queries I will try things and measure the results; in my view anyone who thinks they don't need to do that is either wrong or have achieved a level of knowledge and understanding of the optimiser and data engine that is beyond the capacity of most ordinary mortals (a lot more often the former than the latter). Having got some results I will make sure I understand why they are what they are before I choose a version to put into production. I guess it's that "understanding" step that makes the difference between good and bad practise. But the stuff before that step, the experimentation and measurement, appears to be jiggling, so surely jiggling is only bad practise when it's done blindly and with no intention of reaching any understanding of what's happening?
Anyway, I shall conmtinue happily to "jiggle" to my heart's content as an essential part of my favourite pass-time: learning new things.
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 (after all, hardly anyone cares who did what in 1547, nor what it was that the Jesuits claimed he had done in their Dictionnaire de Trévoux which they published a couple of centuries later; even fewer know; but that doesn't stop people from using and understanding the phrase).
I would argue that you clearly know how and why "un coup de Jarnac" works. It works because everyone has a common understanding of what it means today. It is only its origin that you define as irrelevant 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 23, 2012 at 8:34 am
This is exactly why I have never given developers sysadmin access to either the servers or the databases. Unfortunately, I have been overridden on that a couple of times and it ended up biting the database. I was real tempted to tell management "I told you so" but I didn't. They knew.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
January 23, 2012 at 8:39 am
TravisDBA (1/23/2012)
This is exactly why I have never given developers sysadmin access to either the servers or the databases. Unfortunately, I have been overridden on that a couple of times and it ended up biting the database. I was real tempted to tell management "I told you so" but I didn't. They knew.:-D
You do know that a lot of us devs DON'T want that access. Don't you?
The most privileges I ever want is schema admin, reader and writer granted on a schema that I am to develop. And even then only on a dev box!!!
OK. OK. There are always live issues to deal with but even then should you be granting anything more than reader access on production?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 23, 2012 at 8:43 am
Gary Varga (1/23/2012)
TravisDBA (1/23/2012)
This is exactly why I have never given developers sysadmin access to either the servers or the databases. Unfortunately, I have been overridden on that a couple of times and it ended up biting the database. I was real tempted to tell management "I told you so" but I didn't. They knew.:-DYou do know that a lot of us devs DON'T want that access. Don't you?
The most privileges I ever want is schema admin, reader and writer granted on a schema that I am to develop. And even then only on a dev box!!!
OK. OK. There are always live issues to deal with but even then should you be granting anything more than reader access on production?
It's been my experience over 25 years that a lot more WANT it, than don't, and sometimes management gives in and gives it to them, even when the DBA says no.. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
January 23, 2012 at 8:49 am
Amen.
If only these "code jigglers" would be fired, or reassigned to do something less disastrous we wouldn't have so many problems. However all to often these "jigglers" secure the best job security because their boss is clueless or doesn't want his boss to find out how bad things really are.
Good article.
The probability of survival is inversely proportional to the angle of arrival.
January 23, 2012 at 9:55 am
Jeff Moden (1/23/2012)
GSquared (1/23/2012)
I have to admit, I'm sometimes guilty of "jiggling the code till it unbreaks".I've had to do that in order to teach myself what little I know of XQuery for example. The documentation is abysmal, the online tutorials I've found are shallower than dew on a lawn, and I've had to "try things till it works" more than a few times. So, I have a lot of excuses, and have my practice of this well-justified and thoroughly rationalized (yes, I'm laughing at myself as I type that), but I haven't found a better solution in that case.
At the same time, I'm enough of a hypocrite that I agree completely with Linus on this one, even while I break the rule myself.
I think I know you better than that. For example, you've probably done enough experimentation with XQuery to be able to explain both cause and effect to someone else. I would't put that in the "Jiggling the Code" category. I'd put that in the "well done research" category.
There are parts of SQL XQuery that I understand well enough to explain to someone else. And there are parts where I've had to go "it works, good enough".
Honestly.
I don't usually do that, but I've been forced to by the level of mis- and under-documentation on this stuff. And the W3C documentation on it all seems to have been written by having 1,000 chimpanzees try to type Shakespeare, or more likely Dante since it seems to be designed to put someone through Hell.
Here's an example:
The overview article on MSDN of the XQuery implementation in SQL Server mentions that there are methods that can be used on XML data types, including nodes, value, query, exist, and modify. No links are provided to documentation on these.
Search for "sql server xquery modify" in Bing or Google. The documentation of the "modify" method isn't on the first page of results, just the overview (already mentioned), a bunch of question on a bunch of forums about how to use it, and an article on SSC about deleting XML data. Said article doesn't explain "why" anything, it just has a lot of examples of "how" that are very specific. In other words, the author of the article jiggles the code until it works.
The first 10 pages of search results on Bing don't include an MSDN article on the modify method. Nor any clear documentation of its behavior (third party articles, et al).
Google's results have a Simple-Talk article on page 2, and by page 3 are linking to C# XML implementations.
I happen to have a bookmark that goes to the MSDN article "xml Data Type Methods", at http://msdn.microsoft.com/en-us/library/ms190798.aspx. I didn't find it through search results, I found it through digging through MSDN till I "jiggled" through to what I needed.
Here's what it says about the modify() method:
Syntax
--------------------------------------------------------------------------------
modify (XML_DML)
Arguments
--------------------------------------------------------------------------------
XML_DML
Is a string in XML Data Manipulation Language (DML). The XML document is updated according to this expression.
Note
An error is returned if the modify() method is called on a null value or results in a null value.
Examples
--------------------------------------------------------------------------------
Because the modify() method requires a string in the XML Data Manipulation Language (DML), the samples for modify() are contained in the topics that describe the XML DML statements. For these examples, see insert (XML DML), delete (XML DML) and replace value of (XML DML).
It does have links to the insert, delete, and replace documentation. BUT it took a LOT of homework to just find that, and even then it's horrifically inadequate to actually understand why it works.
These again have very little "why" and rely on examples of "how". Modifying the examples to fit specific needs requires "jiggling" the code, sometimes spending hours changing one variable at a time until it works correctly for all planned test cases.
I have a script library that has a lot of functional XQuery in it. I've documented, for myself, as much of it as I can. But it's sparse, and very, very "script kiddie" in scope and utility. As I find examples of alternative ways to accomplish things in XQuery, I add them to the library. Eventually, I'll reverse engineer enough of it to find more complete, comprehensible patterns.
But I'm not there yet. I research what I can, I script-kiddie jiggle the code for what I have to, and I just keep collecting snippets of documentation, and examples of working code.
Despite all that, based on action in the forums here, I'm one of the people answering questions on XQuery. That scares me, because I know how ignorant I am on the subject. But my level of ignorance seems to be such that questions that otherwise go unanswered, I can help with. A month or two ago, I helped someone speed up an XQuery query from several minutes to under a millisecond, using an XML index and the exist() function. But I trial-and-error jiggled it till it worked, I didn't go "ah, that works that way because ...". I can do that on standard T-SQL. I can usually look at a standard query and, without even looking at the execution plan, can usually tell what areas of it could probably be improved, and know why and how. XQuery? Nah. I'm stuck with, "Maybe this? No. How about that? Yes? What? Why? Huh? Well, I guess it works."
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply