Hearing the phrase "it works" in a certain context makes me cringe. To me, it shows a lack of understanding and commitment to the code. Here is an example of what I mean: Developer One: "How's it going?" Developer Two: "I don't know... I'm having the strangest problems. Sometimes it works, other times it just doesn't return, and other times it just plain crashes." Developer One: "Well, lemme know if I can help." Developer Two: "...... ok... thanks." -- Later that day -- Developer One: "So did you figure out what the problem was?" Developer Two: "Well... I went in and changed a few things around and now '''it works'''." Developer One: "So what was it?" Developer Two: "I'm not sure, but at least '''it works''' now." The phrase is ok when it's used in the context of DoTheSimplestThingThatCouldPossiblyWork, but unfortunately I hear it more often in the aforementioned context. =( -- DrewMarsh ---- I think the ItWorks thinking was why TomVanVleck drew his Three Questions comix. See http://www.multicians.org/thvv/threeq.html -- PeteMcBreen ---- I've noticed that programmers (if we can use that word for these people) who are happy to accept ItWorks also tend to like TestingByPokingAround. I mention this because I have always thought of ItWorks as DebuggingByPokingAround. On the other hand, I have reached points when working with third party components or libraries where I really can't explain why I have to hold my tongue just so to make it work but I don't have the time or ability to find the root cause either. When this happens, I generally write a large comment adjacent to the VoodooFix acknowledging my ignorance and confessing my sins. -- JeffShelby ---- If you are learning how a new library works, you beat on the example code and your own wrapper code until ItWorks. Then you back up the project, and then you add lots of conditions in your UnitTest''''''s on the wrapper that stress the library in ways you know you can get away with, in ways you know your app will need, and in MonkeyTest ways. And you pay attention to stressing your VoodooFix. Only ''then'' do you check in the spike and consider your ass covered. -- PhlIp ---- I use a more healthy form of "ItWorks" (that is very similar to the SimplestThingThatCouldPossiblyWork): I get the basic functionality working and announce that ''"I'm not completely happy with it"'' but that it's '''usable now''' -- "ItWorks." I get all kinds of sour faces, disappointed expressions, from the non-XP developers who wanted the big complex super-feature-gloated version '''''or nothing at all.''''' But it does give the customer and the project manager the opportunity to '''manage''' the project, rather than being forced to decide between (1) runaway costs and schedule or (2) killing the project and losing it all. If the customer still wants all the bells and whistles, they can still have them. All they need to do is pay for them (with time and money). -- JeffGrigg ---- Ah, but adding features to a spike is ''hard''. Drag your feet. But ''stressing'' a spike is ''easy''. Tell it to do 10,000 random records and see what happens! -- PhlIp ---- Sometimes when you have a strange bug, and you make some exploratory changes to your code to narrow down the cause, all of a sudden ItWorks without you knowing why. This puts you in an uncomfortable dilemma: If you proceed to really find out what's going on, if feels like you are futzing around without adding business value. If you go on to the next feature, it feels like giving up and leaving a problem that just might bite you again later. -- FalkBruegmann ---- Sometimes you have to KludgeItTillItWorks ---- I have nothing against Kludges... a kludge is magic to the novice, but to the experienced programmer it makes perfect sense and is often the only good solution... as I understand the start of this topic the rant is about a total lack of understanding or interest in the workings of an application. This leads to flacky [?] bugs as described by the initial quote. for instance a 'return' statement without a value when the function is declared as int. sometimes it works, sometimes it doesn't... if you don't know how you fixed it, how do you know its fixed? maybe it's a different bug now? I'm with Mr Shelby above in wondering if we should really call them programmers, although I don't mind if they will take on the title of novice. I've made it my business to know the inner workings of computers all my life, now I meet people who don't realize that a program can compile and run for two days but them crash because of a misplaces colon, coma or other symbol, this is a novice who should either sit with an experienced programmer for a while, or stick to projects where they can't hurt anyone. If we are going to talk about adding business value, then I guess we better ask if we are on the Microsoft plan. Does business value include system uptime? As I said, if you don't know how the bug was fixed, it probably wasn't... here is an example, a memory problem in an application causes it to crash sporadically; in order to identify the issue, you put in a few print statements, then it stop crashing, so you start to take them out, until is starts to crash again... there is no magic here - when you add code, you change the structure of the program - you could leave some of the print statements in the code, but there is still a bug and it will cause a problem eventually. Maybe it will crash, or maybe it will change a dollar amount on an invoice. Sounds like business value to me... (Please excuse the rant, I'm passionate about my job...) -- DavidDelikat ---- ItWorks was also the name of a larger Norwegian IT consulting firm. ''I''''''tsNowBroke. (As in OutOfMoney)'' -- ThomasEyde ---- ItWorks is also a defense given by one who has written perfectly good code and has used a scheme or method that one who has been placed in a position of judging the quality of it has not considered, or will not consider, correct for their own coding style. Those who write code which departs from the tried and true, we've-always-done-it-this-way style will often be placed in powerless defensive positions for which the fact that "ItWorks", is not enough. The fact that it might be done in another way (which is obvious), becomes the method by which the critic can justify passing of the responsibility of coding to another who codes in a manner the critic is more comfortable with. This should not be, but often is, the case. :In such a context, ItWorks is an inadequate defense. There turns out to have been some requirement of the code that the programmer did not take into account. Perhaps this requirement (or constraint) should not apply. Perhaps it should have been made clear before the code was written. The fact is, though, '''it is now''' a requirement, so the code is not "perfectly good". It may be "perfectly good" functionally and in some non-functional respects, but there is (at least) one NonFunctionalRequirement that is not met. ---- I've come across this many times as a defense against good practices and clean-up efforts, frequently on massive legacy code bases. "It's worked fine for the last 16 years. Leave it alone." I'd be willing to accept that if it wasn't code that we had to touch frequently (implying that it's only been working since the last time it was touched, truth be told) and was too goopy to manage. ---- ''To say ItWorks! is at least a little better than to say ItDoesntWork. I prefer to target my efforts towards the first'' -- DonaldNoyes ---- "I'm not sure, but at least it works now." ...has come to be a 'code' with our guys...Translation; "I did everything i could and it was a finger-problem or simply a laspe in verification and i'm embarrassed to say the solution was so simple!" eLearning at its best ---- I had this same conversation just this morning with a client who is "porting" a dryer appliance control from an old Panasonic 8-bit part to a newer ATmega64a AVR. The control has an upper and a lower display. There's a version of the dryer that only uses the lower display for a single-channel control, but "for some reason" the existing software has to use the variable space associated with the upper display for the single unit. I expressed my concern that the reason could easily be a (barely) hidden bug that will raise its ugly head as soon as I try to get the application running on the AVR. We shall see. -- MartySchrader ---- The most common ItWorks that I see hasn't been mentioned yet: "It's ugly, I don't like it, there's even a little copypasta and a hardcoded magic number. We should definitely come back and make it cleaner and more flexible and general. Ideally, we'd do x, y, and z. But it works, and we don't have time now. We have to get it deployed." ---- See: ProofByUtility, LegacyStamp, ShapeWhatYouCanControl Contrast: ItDoesntWork, ProveIt, VoodooChickenCoding, BreakOrDestroyItThenMakeItNew ---- CategorySuccess