Become a Technological Historian

Question

Become a Technological Historian

Grant Fritchey

SSC Guru

Points: 398909
More actions
October 26, 2019 at 12:00 am

#3691666

Comments posted to this topic are about the item Become a Technological Historian
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004412 More actions · Answer 1

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.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Eric M Russell SSC Guru Points: 125562 More actions · Answer 2

This is why we should comment our source code and version control checkins - so those who follow us can better understand why we did things the way we did.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Grant Fritchey SSC Guru Points: 398909 More actions · Answer 3

Eric M Russell wrote:

This is why we should comment our source code and version control checkins - so those who follow us can better understand why we did things the way we did.

Assuming you're doing the right thing and have your code in source control. It's still only barely half of most database teams that do this.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Tom Gillies SSCrazy Points: 2761 More actions · Answer 4

I liked this article too. Even if we don't aspire to be "technological historians" we can at least take and interest in technological history, if for no other reason than making life more interesting for ourselves.

IMO taking this approach will address two fallacies:

That WE are smarter than THEY were, and
That THEY were smarter etc...

Because, the truth is as Grant says, that neither they nor we are that good at foretelling the future.

Often design decisions are made because of the technology or tool constraints at the time the decision was made. Or maybe the requirements have actually changed significantly over time.

Which leads on to the next points:

Documenting "why" something was chosen can be really useful and it only takes moments.
Understanding "why" something was done, may enable us to learn from someone else's mistakes...
...Or prevent us from making new mistakes of our own!
And if the requirements really have changed significantly, maybe realising that will save us from making a lot of piece-meal changes when what we should be doing is something a little more widespread and controlled.

Yup, I think I'll add "Technological Historian" (or even "archaeologist") into the list of things I should try to be ;-).

Tom Gillies LinkedIn Profile www.DuhallowGreyGeek.com[/url]

Jeff Moden SSC Guru Points: 1004412 More actions · Answer 5

Grant Fritchey wrote:

Eric M Russell wrote:
This is why we should comment our source code and version control checkins - so those who follow us can better understand why we did things the way we did.
Assuming you're doing the right thing and have your code in source control. It's still only barely half of most database teams that do this.

Interesting stat. I'd be interested on where you got that stat because I'm personally interested in several other stats such as "What percentage of companies that use databases actually have a 'Database Team'"?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 736494 More actions · Answer 6

That stat has been gathered in survey's we've contracted out for from Redgate Software. Each year we hire professional surveyers to contact database people across a wide range of industries and organizations. The results are published in our State of Database DevOps survey, which I believe for 2019 had the number of 53%.

MVDBA (Mike Vessey) SSC-Insane Points: 21797 More actions · Answer 7

Jeff Moden wrote:

Grant Fritchey wrote:
Eric M Russell wrote:
This is why we should comment our source code and version control checkins - so those who follow us can better understand why we did things the way we did.
Assuming you're doing the right thing and have your code in source control. It's still only barely half of most database teams that do this.
Interesting stat. I'd be interested on where you got that stat because I'm personally interested in several other stats such as "What percentage of companies that use databases actually have a 'Database Team'"?

At SQL in the summit I was very surprised at how many people we chatted to didn't have source control for SQL but they did for C#

It was even more interesting that those that did have source control, didn't have automated builds

MVDBA

Grant Fritchey SSC Guru Points: 398909 More actions · Answer 8

MVDBA (Mike Vessey) wrote:

Jeff Moden wrote:
Grant Fritchey wrote:
Eric M Russell wrote:
This is why we should comment our source code and version control checkins - so those who follow us can better understand why we did things the way we did.
Assuming you're doing the right thing and have your code in source control. It's still only barely half of most database teams that do this.
Interesting stat. I'd be interested on where you got that stat because I'm personally interested in several other stats such as "What percentage of companies that use databases actually have a 'Database Team'"?
At SQL in the summit I was very surprised at how many people we chatted to didn't have source control for SQL but they did for C#
It was even more interesting that those that did have source control, didn't have automated builds

Yep.

I've been pushing more and more to just get people in source control. By itself, no automation or another cool DevOpsy stuff, source control has benefits. Just gotta convince people.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

MVDBA (Mike Vessey) SSC-Insane Points: 21797 More actions · Answer 9

Grant Fritchey wrote:

Yep.
I've been pushing more and more to just get people in source control. By itself, no automation or another cool DevOpsy stuff, source control has benefits. Just gotta convince people.

Hahaha , source control was my first objective - you should see the faces of a few people after I dropped the GDPR bomb this morning.

MVDBA

drew.allen SSC Guru Points: 76997 More actions · Answer 10

I certainly would love to know the thinking behind the decision to write <Field1> + (-1*<Field2>) instead of just writing <Field1> - <Field2>. I'm seeing it in multiple places in this old code that I'm reviewing.

Drew

J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA

Jeff Moden SSC Guru Points: 1004412 More actions · Answer 11

Steve Jones - SSC Editor wrote:

That stat has been gathered in survey's we've contracted out for from Redgate Software. Each year we hire professional surveyers to contact database people across a wide range of industries and organizations. The results are published in our State of Database DevOps survey, which I believe for 2019 had the number of 53%.

Thanks, Steve. I found and downloaded that paper (got hit with two emails from marketing people after that). Once of the things that disappoints me with such surveys (and it's patently not just RedGate) is how little participation there is. RedGate made the claim of having over 1000 respondents from all over the world. According to the Department of Labor, there are over 131,000 people carrying the title of Sr. DBA alone in the USA, never mind Developers, etc. 1000 world-wide is a paltry sample. I'm thinking that RedGate has more customers than that.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 736494 More actions · Answer 12

This isn't a Redgate survey. It's a contracted survey that includes our customers, but there are plenty of non-customers in there. It is hard to get people to respond to surveys, which is a shame.

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 13

I love the technical historian brand of games. I call them a "brand" of games because they can take on a number of different flavors. For example:

"The Zombie game": this is the recurrent nightmare of a request that keeps on popping up every few years as a request, usually for a review and a hot "new" way to do things, which ends up looking EXACTLY the same as the previous recommendation, but needs to suck up months upon months of revalidation to prove that it is still too costly to do right and not worth doing the easy way.
"The Doppelganger": this one usually shows up as the new shiny object being dangled on wired, CNET or CIO.COM. The snake oil to cure all ills, reporting without needing to develop a thing, a system that infers your request simply by listening to you snore at your desk..... Upon closer look it's just a shiny coat of paint on top of an old tech, a company being bought out and remarketed as the newest thing out there or simply the pendulum swinging back to where it used to be, etc...
"A new hope": Usually triggered by new technical leadership. Your entire technology stack needs to switch over to another stack and you need t SWITCH now. You obviously haven't reviewed the pros and cons, because otherwise you'd be on the OTHER side of the fence (and everyone knows it's greener over).

Interestingly, by now all of these mini-games usually result in the same outcome, i.e. find an old document put together by your predecessors, find and replace the old technology/request name with the new technology/request name, update the doc date, save, publish, and...<poof>

Like I said I LOVE the technical history game 🙂

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?