Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
To step away from talking about normalization (which I'm sure some people will talk about), I think there's the (correctly identified) larger issue of different reactions to different techniques, etc.

Consider the current "fad" (and I say that without meaning to imply that it's wrong) of "don't optimize until you need to". Well, years ago, when memory and cycles were tight, the answer to "When do I need to?" was usually "from the beginning." These days, cheaper memory, broader I/O, and faster CPUs means that we tend to write for readibility and optimize only when we absolutely can't avoid it.

I think there needs to be a happy medium between "old blood" and "new blood". More experienced developers (, designers, engineers, admins, etc) bring the knowledge of what else to think about and how to think through a problem. Less experienced (but probably more current) developers, etc., bring newer approaches. I think the major conflicts arise when the two camps are unwilling to see the benefits that the other camp brings.

I can't even begin to count the number of times that I've seen someone start tearing off on an OO implementation of something without thinking through what they're doing, only to need to stop in the middle and completely redo their object design. (Heck, I've done it myself when I discovered I overlooked something.) While someone more experienced in OO design would make sure they got closer to "right" before starting to implement.

The flip side, though, is that someone who's steeped in OO doesn't have the same understanding that functional-oriented programming isn't evil and, when done properly, provides many if not most of the benefits of OO. I was doing cohesive and functionally complete "modules" in assembler and C (and lots of other languages that aren't that relevant these days :-) before I ever heard the word "object". It just made sense to make the pieces of a program distinct bits so that tweaks to one didn't automatically ripple through the entire structure.

To point back a little to your DBA - having not done much normalization, he may not have understood the reasons that it makes a difference to a developer, architect, etc. It would have been a perfect opportunity to teach him why normalization is important. Show it from the perspective of:

  • scalability and performance - "Well, sure, we can blaze through with full-table scans, but if we had things properly indexed and normalized, we could get by with much faster index lookups and, instead of being able to support 20 simultaneous hits, we can scale up to 2000."
  • maintainability - "Take a look at how much code needs to be written to support this. Whereas, if it was normalized, we could cut it down to this much, which, as you can imagine becomes much easier to maintain and much less likely to have lots of bugs in it."
  • Pick your own perspective here

I firmly believe that it's important to use any opportunity to instruct. Otherwise, how will the new blood come to understand that the old blood has valuable lessons to teach (and is also willing to learn).

So, in summary, yeah, there's lots of "new blood" that don't respect (or pay attention to) the more experienced folks. But there's enough of the opposite that everyone winds up losing (imho).


In reply to Re: (OT) Old blood versus new blood by bmcatt
in thread (OT) Old blood versus new blood by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others examining the Monastery: (6)
    As of 2014-11-24 03:53 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My preferred Perl binaries come from:














      Results (135 votes), past polls