Modeling and Design Are More Important in DevOps

  • Comments posted to this topic are about the item Modeling and Design Are More Important in DevOps

  • DevOps at its core is "talk to the people involved BEFORE changing stuff".

    Nice theory. Never works.

    The real problem is the illusion of simplicity. A person with decision authority is seldom the person who understands the implications of this "tiny change". You know, "it's just a simple calculation change!" or "How hard can it be to add this one tiny field?" or "we just need to add another column to this report (said report already being 11 inches wide with 20 columns) oh, and can you increase the font size because it's so hard to read. What? No, leave everything on ONE line. Jeez. You want me to show you how to do it?" (said sarcastically by the person with 0 computer experience to the senior developer).

    Because we make it so simple looking people assume it's child's play to make changes to what is in effect 10 levels of abstraction. They don't want to hear the details, just "do this one little change, damn it! Quit making a federal case out of it. I swear, all you people say is no!"

    It's even more fun when it's sales people selling new "features" (that don't exist).

    /rant (haven't had my caffeine this morning) :doze:

  • Since we build our software on the data, we need to ensure we are properly capture the data in a way doesn't create too much technical debt. There are many, many stories of organizations that struggle to grow their applications over time, often because of very poor data models. Many of these issues could have been avoided by consulting with senior developers, DBAs, and data architects/modelers for an hour before making a fundamental change. Even if this means keeping a consultant on retainer.

    Yes, a Data Architects are like dentists, the development team should consult them on a regular basis to get feedback and suggestions for best practices 😀
    ... not just run to them for help when something goes seriously wrong. :crying:

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

  • Gotta disagree here based on the title.  Modeling and Design have ALWAYS been and CONTINUE to be important.  DevOps doesn't make it more important.

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

  • First, aggressively pushing table and index changes are something that's typically done during the prototyping and development stage. If you're doing this post-production, then that indicates poor planning.
    Secondly, many DevOps deployment tools are not robust enough to push database deployments that run for longer than half an hour or more.  The problem is that the tool often wraps all the changes in one transaction (a problem if you're adding a column to a table with 10 million rows) or the tool contains hard to diagnose timeout constraints embedded somewhere in the client stack. Our organization does leverage CI tools to push things like stored procedures or new tables, but DDL ALTER and DML UPDATE/DELETE operations often get submitted to the DBA team using a different deployment channel (sometimes after a first attempt at using the CI tool bombs).

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

Viewing 5 posts - 1 through 4 (of 4 total)

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