The Computing Revolution

  • Comments posted to this topic are about the item The Computing Revolution

  • From my admittedly aging perspective, I think sometimes the best 'revolution' is to go back and rethink and simplify things and make sure we are doing this the best, most accurate. and most efficient way.  As with so many things in life, we keep adding and building and creating things, many times without rethinking and updating and improving what we have and are currently doing.  There used to be an expression 'more better' which you don't hear much anymore.  Maybe we are to the place where we need less emphasis on the 'more' and more emphasis on the 'better'.  Often what we see in revolution is a desire to back up and redo things to get back to the original concept and meaning of what we do, or even to entirely redirect things in a new way. This can often be expressed in the actual tearing down and destroying something in order to simplify, redirect, and improve things.  As we all know, in our line of work, patching and patching and patching does not always improve things all that much.  Momentum can be a good thing to promote improvement or a detriment to be overcome to actually improve processes.  The key to the whole thing seems to be critical thinking that is difficult or nearly impossible due to bias and prejudice.  I can recall many times in the past when we were designing systems and databases, ideas would be brought to the process which sounded good and logical and 'nice', but often were not really of great overall value to the task at hand.

    This reminds me of any number of bits of wisdom I've heard over the years, maybe one of the most most applicable being 'Be careful what you ask for.  You just might get it'.  And another, 'Do we really want to do this?'.

    We need to be absolutely certain that any 'Computing Revolution' is going to have constructive results that we can live with.

     

    • This reply was modified 4 years, 4 months ago by  skeleton567.
    • This reply was modified 4 years, 4 months ago by  skeleton567.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • I tend to agree with you, that we often should rethink what we've done. Too many times we get stuck in the sunk cost fallacy, which is bad. We have the ability to throw away and restart with less issues than anything in the physical world, which should let us move faster with a new design/approach from the beginning using our knowledge.

    I do think that this is harder the more that something is in use. It does become hard and painful to not try and patch things. That does work in cases, but even when it's the best decision, we ought to have stepped back and rethought things.

    I think I did that recently with my lawn mower. Rather than try and rig something on the 18 year old deck, I just ordered a new part. Partly because they are likely to become very hard to get in the future and partly because it's simpler than anything else.

  • I got an "all in one" Compaq in 1995. It had 8 MB of RAM, which I eventually upgraded to 16. Even more memorable was the 420 MB hard drive. I always think back to that machine when handling a 128 GB (or bigger) thumb drive. Rather remarkable.

    Trying to figure out the world of SQL as marketing consultant for SQL Solutions Group https://sqlsolutionsgroup.com/

  • Steve Jones - SSC Editor wrote:

    I think I did that recently with my lawn mower. Rather than try and rig something on the 18 year old deck, I just ordered a new part. Partly because they are likely to become very hard to get in the future and partly because it's simpler than anything else.

     

    My point exactly.  Situation is now that you still have an 18 year old mower.  I'm sure there are other considerations also.  Maybe it's time for a revolution?

    • This reply was modified 4 years, 4 months ago by  skeleton567.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • I watched Kevin Scott's presentation live. It was very interesting. Highly motivational.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I've trying to avoid the $2k revolution if I can 😉

  • Great article Steve. Really informative.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • Thanks, if you watch the video, it's really neat.

  • skeleton567 wrote:

    From my admittedly aging perspective, I think sometimes the best 'revolution' is to go back and rethink and simplify things and make sure we are doing this the best, most accurate. and most efficient way.  As with so many things in life, we keep adding and building and creating things, many times without rethinking and updating and improving what we have and are currently doing.  There used to be an expression 'more better' which you don't hear much anymore.  Maybe we are to the place where we need less emphasis on the 'more' and more emphasis on the 'better'.

    ...

    With Azure, it's great to be able to spin up a database without having to install SQL Server, to scale out replicas without having to configure or even know about replication or AOG, to instantly scale CPU / Storage / Memory up or down without taking a server box off the rack. It's not just more - it's virtually limitless and even simpler.

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

  • Eric M Russell wrote:

    skeleton567 wrote:

    From my admittedly aging perspective, I think sometimes the best 'revolution' is to go back and rethink and simplify things and make sure we are doing this the best, most accurate. and most efficient way.  As with so many things in life, we keep adding and building and creating things, many times without rethinking and updating and improving what we have and are currently doing.  There used to be an expression 'more better' which you don't hear much anymore.  Maybe we are to the place where we need less emphasis on the 'more' and more emphasis on the 'better'.

    ...

    With Azure, it's great to be able to spin up a database without having to install SQL Server, to scale out replicas without having to configure or even know about replication or AOG, to instantly scale CPU / Storage / Memory up or down without taking a server box off the rack. It's not just more - it's virtually limitless and even simpler.

    Agreed and true, Eric.  Just be sure to keep up the original skill sets in case some new job opportunity should require them.   When things become too easy, we tend to get lazy and drift away from the things that add value to our abilities.  I recently read an interesting piece regarding a growing demand for - hold your hat - COBOL programmers and offers of quite high salaries, all because of ancient systems that few can handle now.  I didn't use COBOL after the early 70's, but could probably brush up on it fairly quickly.  We were doing highly structured coding in those days, had to handle our own overlays, the whole works.  Had to print our program listings 11 x 14 7/8 paper on the old rotary chain-type printers, interactive programs could run 60 or 70 pages of code.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • skeleton567 wrote:

    ...

    Agreed and true, Eric.  Just be sure to keep up the original skill sets in case some new job opportunity should require them.   When things become too easy, we tend to get lazy and drift away from the things that add value to our abilities.  I recently read an interesting piece regarding a growing demand for - hold your hat - COBOL programmers and offers of quite high salaries, all because of ancient systems that few can handle now.

    ...

    Yes, having COBOL on one's resume would open some doors, at least for government contractors. My concern would be maintaining the legacy hardware where parts and support are becoming scarce. One option is migrating the COBOL environment to a mainframe emulator in Azure. It looks and feels just like the old system but can now scale CPU and storage as needed and run the terminal from any web enabled PC. That would be my angle.

    https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/mainframe-rehosting/partner-workloads

     

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

  • Eric M Russell wrote:

    skeleton567 wrote:

    ...

    Agreed and true, Eric.  Just be sure to keep up the original skill sets in case some new job opportunity should require them.   When things become too easy, we tend to get lazy and drift away from the things that add value to our abilities.  I recently read an interesting piece regarding a growing demand for - hold your hat - COBOL programmers and offers of quite high salaries, all because of ancient systems that few can handle now.

    ...

    Yes, having COBOL on one's resume would open some doors, at least for government contractors. My concern would be maintaining the legacy hardware where parts and support are becoming scarce. One option is migrating the COBOL environment to a mainframe emulator in Azure. It looks and feels just like the old system but can now scale CPU and storage as needed and run the terminal from any web enabled PC. That would be my angle.

    https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/mainframe-rehosting/partner-workloads

     

    That makes lots of sense to me.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Heh... "Computing Revolution".  I call it the "Dust Revolution" because data and code is just like dust... it accumulates on horizontal surfaces (and sometimes sticks to vertical surfaces in the form of cobwebs).  The bigger the surface, the more dust there is.  Very much like a bad drug habit, it's self-perpetuating and the more you use it, the more you need it and the more you do it.  A lot of programmers have forgotten how or never learned to "dust" things off. 😀

    The really cool part is that it's been beneficial to us old farts in many ways.  I was the big kid on the block way back when I bought my first computer.  It was an OHIO scientific computer and I had a whopping 8 KILO bytes (twice as much as my friends had) and BASIC in ROM along with a cassette drive interface so I could store my programs on tape and easily retrieve them.  It was amazing what I could do on that machine especially when I connected it to external devices.

    I went through it all... I remember the incredible upgrade I was able to do on one of my machines from 512K of RAM to a whopping 640K of RAM and had a 40MB hard card installed (it HAD to be partitioned because DOS couldn't handle drives more than 30MB at the time.

    I remember my first 1GB drive.  It cost me $1,000 USD plus I had to buy the SCSI interface card to use it.  I was sure that I'd die of old age before I ever filled up such a drive.  I also got my first 9600 Baud modem card at the same time.

    Now I have single column non-clustered indexes that are more than 50 times that size.  I also have a reasonably recent laptop with 6-core i7's threaded to 12, 32GB of RAM, a 2GB harddrive, and 2GB of high performance SSDs (reminds me of a RAM drive but certainly much better).

    Performance challenged code and very large databases continue to grow, mostly because a lot of people are on the hardware drug.  The cool part is that as more nearly useless data grows, so does the technology to store it and retrieve it quickly.  Communications between computers has also increased (imagine a 9600 Baud connection nowadays... I actually started with a 300 baud modem).

    The self-perpetuating drug of trying to use hardware to make our code faster and keeping everything has forced the hardware industry to get better and better and, as it does, more and more computational "dust" settles requiring still better hardware.

    The good part about all of that is that people that DO write good, high-performance code are in demand, especially when it comes to data and databases.  And, we don't necessarily need to use or even learn all the bright-shinny new stuff that frequently lasts about as long as a flash in a pan.

    A lot of that new stuff is created just because people don't "dust" any more.  They also don't know how to keep from creating lots of "dust" when they design a database or write code to use it 😀

    Some ask me what I do for a living... I sometimes tell them "I'm the cleaning lady... but I don't do Windows". 😀

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

  • Jeff Moden wrote:

    The really cool part is that it's been beneficial to us old farts in many ways.  I was the big kid on the block way back when I bought my first computer.  It was an OHIO scientific computer and I had a whopping 8 KILO bytes (twice as much as my friends had) and BASIC in ROM along with a cassette drive interface so I could store my programs on tape and easily retrieve them. 

    My first was a Radio Shack TRS-80 Model 1 that you plugged in to the TV and my first coding language was ASM.  🙂

    Far away is close at hand in the images of elsewhere.
    Anon.

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

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