I like this article a whole lot. Thanks for taking the time to write and publish it, Grant.
One of the things in the article is something that a whole lot of people miss out on and so I thought I'd highlight it a bit...
Yes, the old decisions may have been stupid or ill-informed, but there may also have been very good reasons why those decisions were made at the time. A good understanding of why things were done will help you to better improve them.
... and, to be sure, even more people miss out on the exact opposite of that notion. If we rewrite the quote above, you can see what I mean...
Yes, the new decisions may seem incredible and well informed, but there are frequently very good reasons why the old decisions were made that are still very applicable even at this time. A good understanding of why things were done will help you to better understand that you're getting ready to make a huge mistake and need to use the old stuff to improve your "new" decisions, which might actually turn out to be "do it the old way".
With that, I'll also recite a very old truism that is proven true many times every day especially in many areas (if not all) of the world of software...
Change is inevitable... change for the better is not.
Paraphrasing another truism that goes along with that, whose negative basis seems to have become the norm rather than the exception...
Don't mistake the consensus of the crowd as the wisdom of the group.
People seem to really like "new and improved" and the latest "too cool for school" bright and shinny objects. They have to realize that software and software methods shouldn't be treated like the next fashion statement made by people that make tennis shoes where people that can't actually afford to do so suddenly have to have that new pair just because every other idiot in the world is buying them. It also reminds me of the people that will wait in line outside a store on a winter night to buy that new phone only to find out later that it bends and breaks when you put it in your pants pocket or catches on fire when the new "improved" battery runs low or that designer drug you convinced your doctor to prescribe for you because everyone says it's the fix but actually does kill your or, worse, causes a terrible, life changing, disability.
My point is that people make too many decisions based on hear-say, marketing hype, "keep up with the Jones" attitudes, or simply think that the more decisions they make, the better the job they're doing. Too many people think that making a decision is more important than making the correct decision and that bit of lunacy plays itself out every damned day. The idea of "ship it now... we can fix it later" has become the norm rather than the irresponsible and totally stupid thing to avoid at all times. Some people still haven't figured out that 9 women can't make a viable baby in a month. They can, however, make nine really nasty abortions in a month.
Getting back to the article, don't just learn how things were done wrong in the past... learn how things were done right, as well. Then learn that you might simply need to make the decision to use (for something seemingly new and different) or continue to use an old way that has withstood all the tests of time even if that seemingly dated, old way is not the latest and greatest really cool and shinny bobble that all your friends just have to have.
And remember that people also fit into those types of decisions. What does that quiet, seemingly useless old coot working with the younger folks know? The answer is frequently "Everything" even if you're working with new tools that old coot hasn't. The same can also hold true for that young turnip that just fell off the new recruit truck.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)