Using an ‘ooky detector’ to guide decisions

Yesterday I posted an article about configuring Tomcat and Eclipse for debugging, and my general dislike for running an application server and doing non-unit testing within the IDE.
I used the term ‘ooky’ to describe how I feel about this practice, as I have no real rational or definitive logical reason for not doing it, other than “I just don’t like how it feels”.
In one of the comments, Jon Tirsen mentioned that using ‘ooky’ as a means of making decisions isn’t such a great idea. I spent the evening pondering this and wondered why he would make that statement, especially from somebody who likes Ruby more than Java because it is more ‘elegant’. To me, this is clearly the use of an ‘ooky detector’ by Jon.
(Hey, I like Java more than C++ because it’s more elegant as well, and I agree that Ruby is a more elegant language than Java)
My gut feel, and general sense of ‘ookiness’ about people/projects/products/implementations has been a great indicator of success.
Maybe it’s an experience thing. I’ve got 20 years of experiences in which to build up my ‘ooky detection parameters’. If you’ve only got 5, then maybe your ‘ooky detector’ isn’t well calibrated.
I’ll happily admit that I’m often wrong, but these days I tend to be more right than wrong, and every decision that I make helps me calibrate my ‘ooky detector’ even further.
Why do I think using an ‘ooky detector’ works well ? Most of the time we are working in grey areas, and there is no absolute right or wrong. The concept of smells in code is very much a specific example of an ‘ooky detector’ and in many cases people have different calibrations for their code smell detection than others.
I think that if we examine many of the decisions that we make on a day-to-day basis, most of them have very little deep analysis and concrete decision making process, and we (as humans) tend to using an ooky detector.

Advertisements

12 thoughts on “Using an ‘ooky detector’ to guide decisions

  1. One problem with using “feeling ooky” as a means of making decisions is that it’s harder to learn anything new.
    Example:
    One might feel a bit ooky about using Ruby because it’s a dynamically typed language. Problem is that you’re not taking a change in engineering practices into account: We’re now doing automated testing to a much higher degree than before. A test is a much better way of validating functionality than statical analysis by a compiler.
    “Ookyness” doesn’t take this into account because it’s not an intelligent analysing process, it just takes whatever you’ve experienced in the past into account not current events and innovations. I guess you can use “ookyness” (aka intuition) to guide you in the right direction, but you need to use actual facts to make decisions.
    And you’re “ookyness” was wrong about Jetty inside Eclipse for pretty much the same reasons. What have your “ookyness” actually been right about? πŸ˜‰

  2. I said I had nothing against running Jetty inside an IDE when doing unit testing. In fact, I think it’s a great idea. Wow, surprise. Why was it wrong, when I said it was a good idea ? Hmm, maybe reading and comprehension ?
    What I feel ooky about is running a container, then driving the container via a browser launched within an IDE.
    Most of my ooky feelings don’t prohibit me from doing things, and generally I’ll try them to see if my concerns are eased. For example Ruby is a great language, scripting languages are cool. There’s nothing inherently ooky about a scripting language.
    Letting the general unwashed masses use scripting language to develop enterprise applications is ooky.
    Here’s some things that my ookyness has guided me successfully.
    Groovy – how’s that going ? Been a couple of years now since that was going to take over the world. Seems to be somewhat MIA. Most of the ADD fanboys have jumped to RoR.
    JavaEE – the “choke to death” smorgasboard approach never sat well with me. I didn’t know how to solve the problem, but never accepted that “monolithic frameworks” were the answer.
    Going drinking with David Hook. ’nuff said. Didn’t stop me from doing it πŸ˜‰
    Notable people within ThoughtWorks who shall remain nameless. Their self absorbed, know everything attitude and preaching without listening was an immediate ooky indicator. So far, it’s proven to be 100% correct.
    Some things my ooky detector didn’t work so well.
    IDE’s. I was against using IDEs for a lot longer than I should have been. Part of the reason was that I was never introduced to a _good_ IDE (such as IDEA) early enough.
    Consulting. Urk. Worst career choice ever.
    At the end of the day, I can look back at my career/life and the decisions I’ve made, with my decision making process and be pretty happy. Don’t use it if you don’t like it.

  3. Ooky. I like it.
    Making a decision based on ookyness does make sense to those who also have a similarly tuned ooky detector, but to those whose opinions of ookiness
    are different, then further evidence is required.
    It’s actually not that difficult either. Lies, damn lies, and statistics. Using WHY you think something is ooky as the place to start gathering the evidence. πŸ˜‰
    I think using ookiness as the sole indicator for the decision is a bad idea, but if it causes further investigation into why you feel ooky, then it’s great.
    “self absorbed, know everything attitude and preaching without listening” – that’s backing up an ooky indicator with some observable actions…
    “the “choke to death” smorgasboard approach” – another reason rather than just an ooky feeling.
    So an Ooky detector is like a gold detector. It helps identify the gold, but it’s then up to you to really find it and dig it up. (Actually, it’s probably more like a **poo detector** but I can’t really see a valid use for one of them, or why you’d want to dig it up either)

  4. Ohhh… Groovy. That was a punch below the belt. πŸ™‚
    You may have a complete lack of respect for us ADD boys but you gotta admit, mate, we are the ones that make our craft keep on developing. Without us ADD boys there would never have been any agile, TDD, Java, object-orientation, garbage-collection, refactoring and so on. Now, ADD boys aren’t *enough*, somebody has to take over when we get bored. Java would never have been the success unless it did quite down a bit after the first couple of releases.
    We ADD boys may take a lot of risks but do eventually bounce back after we’ve gotten burned.
    I have no problems admitting that Groovy was a failure even if my ooky-senses said it was gonna fly. Actually, I’ll say more than that: Groovy could have worked, it had much more rational reasons for working than Ruby/Rails ever did. And I’ll say even more: If Groovy did work Java would have been in a much better spot than it is today. It could have had the chance to age with style and not just be the Cobol of the nineties (ADD ONE TO COBOL GIVING JAVA).
    And my ookyness actually told me that how much I loved Ruby it would never, ever, ever fly. I didn’t like Groovy as much, but it had a much better shot.
    Well, I guess I was wrong.
    Otherwise, I agree with Peter Hancock. Ooky is okay (pun intended) as one input into your decision making process, but it’s not sufficient. Use your intellect and ability to reason and make a decision based on facts available *right now*. Every system you’re building is different, every situation you encounter is unique. Use the ookyness to guide you into what to look for, but then turn it off and actually look at what is going on with an open mind.
    (As for your ooky-senses telling you that ThoughtWorks should stay as far away as possible from Groovy, in hindsight they were just plain wrong. Groovy may not have taken off but ThoughtWorks hasn’t suffered any particular pain from being associated with it. I mean, we’re involved in all sorts of crazy shit that this was just a drop in the ocean. Can you spell i-n-t-e-n-t-i-o-n-a-l? πŸ™‚ )

  5. Oh, btw…
    “Letting the general unwashed masses use scripting language to develop enterprise applications is ooky.”
    Letting the general unwashed masses develop enterprise applications is ooky period. Don’t matter what tool you’ll give ’em they’ll screw it up. You know that as well as I do.

  6. “You may have a complete lack of respect for us ADD boys but you gotta admit, mate, we are the ones that make our craft keep on developing. Without us ADD boys there would never have been any agile, TDD, Java, object-orientation, garbage-collection, refactoring and so on.”
    I have a _complete_ lack of respect for the ADD fanboys, and even less so if they’re trying to claim credit for work that brilliant pioneers that dedicated time, effort and energy to come up with something that nobody else has done.
    ADD fanboys are a useless blight on our industry, as they distract and alienate achievements that would otherwise be adopted in a wider context.
    I’ll give you the benefit of the doubt of a poorly phrased first paragraph to possibly mean the popularisation, or the widespread awareness, rather than invention. If not, and you actually meant the ADD fanboys were responsible for development of these, then you’re more deluded and have a greater over-inflated sense of your self worth than I had imagined.
    But surely not…

  7. This drama pleases me. Its passive aggressive nature is most gratifying. Continue gentlemen. Oh, mike, pass the popcorn down this end.

  8. ‘I guess you can use “ookyness” (aka intuition) to guide you in the right direction, but you need to use actual facts to make decisions.’
    Not quite weasel words, but I can’t let them go by…
    What are “actual facts”? What’s the difference between these and plain, vanilla facts? To me it looks like “actual” is intended to imply that what the other person claimed to be facts aren’t really facts at all.
    Leaving that out, what have we got:
    ‘I guess you can use intuition to guide you in the right direction, but you need to use facts to make decisions.’
    False dichotomy folks – I think (but haven’t verified) that there’s research to show that in many cases intuition is your brain forming subconscious links between *ahem* facts.
    Dictionary.com give me three definitions of intuition:
    1 : immediate apprehension or cognition without reasoning or inferring
    2 : knowledge or conviction gained by intuition
    3 : the power or faculty of gaining direct knowledge or cognition without evident rational thought and inference
    The difference seems to be that we can’t explain the reasoning behind our intuition, so other people don’t find it convincing (trust me on this *s*).
    Both conscious and subconscious reasoning can lead us to false conclusions – it’s good to listen to them both when you make decisions.

  9. ‘You may have a complete lack of respect for us ADD boys but you gotta admit, mate, we are the ones that make our craft keep on developing. Without us ADD boys there would never have been any agile, TDD, Java, object-orientation, garbage-collection, refactoring and so on. Now, ADD boys aren’t *enough*, somebody has to take over when we get bored. Java would never have been the success unless it did quite down a bit after the first couple of releases.’
    Excuse me, but could you list the “ADD boys” that are associated with each of these advances?
    Assertion: Ideas are cheap – verifying/proving the idea is correct, and turning the idea into something that can be used by other people are the hard parts, and these parts aren’t amenable to “ADD boys” (though I’m inferring the meaning of the term and could be way off). Anyway, that’s my intuition, and I’d love to see some actual facts that contradict it. I have an open mind.

Comments are closed.