Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Think about Loose Coupling
 
PerlMonks  

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


Comment on Re: (OT) Old blood versus new blood

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://132612]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2014-04-21 01:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (489 votes), past polls