Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: (OT) Old blood versus new blood

by bmcatt (Friar)
on Dec 17, 2001 at 22:57 UTC ( #132612=note: print w/replies, xml ) Need Help??

in reply to (OT) Old blood versus new blood

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).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://132612]
and God said, "Let Newton be!"...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2017-02-22 04:25 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (324 votes). Check out past polls.