But we've always done it that way…

  • ZZartin (8/3/2015)


    Hmm... what's fun is when good processes get built around bad processes and then the bad processes can't be fixed without redoing a lot more things.

    Then you have a series of patches and work-arounds that are considered a complete system!

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Michael L John (8/3/2015)


    ZZartin (8/3/2015)


    Hmm... what's fun is when good processes get built around bad processes and then the bad processes can't be fixed without redoing a lot more things.

    Then you have a series of patches and work-arounds that are considered a complete system!

    Yes - a vendor of ours has recently coined such a system as the "new legacy application of the future" (you changed the name of the band leader, but the chairs are still on top of the titanic)

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

  • I jokingly refer to my current team as the Bondo Group. So much changes from data to day with processes, but nothing ever really changes. Just more layers get added...

    Aigle de Guerre!

  • So, why did the chicken cross the road? Because he's always done it that way. 🙂 Why won't he stop? Because he's never tried that before. 🙂

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

  • In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

  • On the other side of the same coin...

    I won't support change for the sake of change or for the sake of someone being a cool kid that just deployed the latest version of a rubber chicken. I've found that too many people simply can't resist the latest shiny object even if it has a negative ROI. That's not to be mistaken with the "we've never it done it that way" syndrome. If someone has got something good, they need show me that it's good (as in better than what we have) and I'll help them champion what ever it is. If they can't demonstrate that it's actually better, then it's just another rubber chicken and they need to calm the hell down until they can. 😉

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

  • xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    "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

  • Change is certain, progress is not. To build on that, change for the sake of change is less likely to produce progress. Progress requires change, but also requires planning.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    I can tell you that in my and my co-workers cases, we found it difficult to leave. This is mainly because the company was making video games and there were few to no other game companies really in the entire country. It's one thing to move across country for work, it's another to move out the country.

    Outside of that, the industry is very competitive. When you finally get in, it's not as easy to just move. This isn't the same as me working in multiple industries within my city as a SQL Server guy. The industry is limited and therefore, you have to put up with the bad way of doing things much more than you would want.

    So, it's easier said than done to point out all the stuff we want to change in any company. It's not so easy making that happen in the areas I've experienced let alone just pick up and leave when they don't make those changes happen.

    Consider yourself lucky if you have the option to just pick up and leave for another job in your area let alone your country.

  • Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    The unfortunate part is that there are far too many people, as well as entire organizations, who cannot recognize that they ARE in a position of pain. "Arrogance of ignorance" is the norm. The end user experience is poor at best, but they never knew any better.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    This reminded me of the story used to explain the expert beginner. http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2
  • xsevensinzx (8/4/2015)


    Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    I can tell you that in my and my co-workers cases, we found it difficult to leave. This is mainly because the company was making video games and there were few to no other game companies really in the entire country. It's one thing to move across country for work, it's another to move out the country.

    Outside of that, the industry is very competitive. When you finally get in, it's not as easy to just move. This isn't the same as me working in multiple industries within my city as a SQL Server guy. The industry is limited and therefore, you have to put up with the bad way of doing things much more than you would want.

    So, it's easier said than done to point out all the stuff we want to change in any company. It's not so easy making that happen in the areas I've experienced let alone just pick up and leave when they don't make those changes happen.

    Consider yourself lucky if you have the option to just pick up and leave for another job in your area let alone your country.

    Unclear again. My apologies. I didn't mean "position" as in job. I meant "position" as in process/software/resource that is causing pain to the organization/team/individual. Sorry for the lack of clarity.

    I'm absolutely not advocating people quit their jobs because there is one, or more, silly process.

    What I am saying, however poorly, is that if, one finds oneself in the situation where, a process that appears foolish, and is actively hurting the organization AND the reason that you're doing the process, despite the clear pain, is stated "Well, we've always done it that way" then, I would say that action must be taken.

    I'm not questioning any individuals situation.

    I'm not saying this will be easy.

    I'm not saying you'll always succeed.

    Again, I haven't advocated for anyone quitting work or changing careers.

    I am saying that rolling over and letting it continue sure isn't likely to lead to any good outcomes.

    An example. I just read on a different forum entirely how someone had a RAID system crash. Turns out they didn't have backups working properly. They knew the backups were failing, but didn't do anything about it. Now, the database is corrupt and they don't have any means of recovery. What do they do now? Very few options now, right. But, earlier, they knew the backups were failing. Now, if just the individual knew this and did nothing, they probably deserve what they get. How many of us have been in situations where the boss says "We don't have time to worry about that now." So, you put it off. Then, pay for it later. They've never had a RAID crash before, or, if so, it never caused corrupt databases, so, we've always just not worried about those backups. We've always done it this way. It works until it doesn't.

    As subject matter experts, it is our job to advocate for the right way to do things. We're supposed to be the ones to protect the systems, especially when there is ignorance within management or the business. They hired us to be their ignorance solution. So, yeah, I'm saying, you need to do that. Be the subject matter expert.

    "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

  • xsevensinzx (8/4/2015)


    Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    I can tell you that in my and my co-workers cases, we found it difficult to leave. This is mainly because the company was making video games and there were few to no other game companies really in the entire country. It's one thing to move across country for work, it's another to move out the country.

    Outside of that, the industry is very competitive. When you finally get in, it's not as easy to just move. This isn't the same as me working in multiple industries within my city as a SQL Server guy. The industry is limited and therefore, you have to put up with the bad way of doing things much more than you would want.

    So, it's easier said than done to point out all the stuff we want to change in any company. It's not so easy making that happen in the areas I've experienced let alone just pick up and leave when they don't make those changes happen.

    Consider yourself lucky if you have the option to just pick up and leave for another job in your area let alone your country.

    Perhaps you're in the wrong industry. It seems a lot of us here are having existential thoughts about our careers the last couple of years.

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

  • Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    I guess this is a matter of how much pain are you in. I have often chafed at how slow change can be, but I suppose that's part of the process. There has to be that balance between continuously throwing out the baby with that bathwater and blindly marching over the cliff you see ahead of you. In other words: understand why the change is really needed, prove that the "new state" is in fact better than the old state, and handle everything that was started in the old way so that it isn't just left dangling. Oh and still keep all of the lights on and the organization still moving.

    I've come to look for organizations where I at least can have *some* impact on improving the situation. At least if the mindset is there, you can negotiate to accelerate changes as needed. If the mindset is solidly stuck on "don't change no matter what" or the pace of change just will never be enough to actually get out of the mess you're in, then it's time to leave and find something else.

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

  • Luis Cazares (8/4/2015)


    Grant Fritchey (8/4/2015)


    xsevensinzx (8/3/2015)


    In my years working in software development from a marketing perspective, the right way always seems a bit too subjective from the people who are advocating change. That doesn't mean it's not subjective if you truly sit down and think about it. The problem is how it's delivered and sold.

    At the end of the day, I've come to the understanding that even from a non-software development position, I could point out a dozen of those "but we've always done it that way" examples that are hindering the development, the product and so forth.

    It doesn't matter what I or others would say, it's simply hard as hell to get change. And based on my experience, it's pretty common and mostly attributed to the fact it's easier going in the (bad) direction you already going rather than stopping, considering a new direction and heading into the direction just as quickly as you were before.

    That is very true. It's much easier to continue down the path you're on. But that doesn't make it the right decision. Again, I really don't mean to argue for change just so that we can see change occur. If you're in a position of pain, why not move out of that position?

    This reminded me of the story used to explain the expert beginner. http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner

    Excellent article. Thanks for sharing.

    "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 15 posts - 16 through 30 (of 35 total)

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