Creating vs. Maintaining

  • Comments posted to this topic are about the item Creating vs. Maintaining

  • 100%. Something as simple as naming whatever enitities correctly - and then maintaining that naming scheme ruthlessly when things are refactored - can make the difference between being easily navigable and being wildly frustrating, when you want to find the problematic thing out of 2,000 other things. I guess I get my team to listen to me 90% of the time on that 🤓 We know Ralph Waldo Emerson was not a programmer when he said "Consistency is the hobgoblin of little minds"...

  • One of the things I learned from this site early on (2 decades ago) was that if you get your data model right it works, performs and lasts.

    When I worked as a DBA for Moneysupermarket, the need for reliability was hammered into the SQL DBA team (RIP).  Downtime costs big money.  Genuine reliability requires a slew of disciplines.  No-one likes to be called at 03:00, especially when the sleep deprivation of parenthood is at its worst.

    With those factors shaping my career I've always developed with the idea that I'm probably going to work in close proximity to someone who has to maintain what I produce and knows where I live.  Reliability and maintainability were paramount

    My experience was that DBAs were left behind in the great Agile rush, and I think that is largely because the knowledge for developing/maintaining a stateful system within that paradigm was sparse to non-existent in the market place overall.  Agile became a dirty word to sum up a whole raft of bad behaviours badged as Agile.  This was a shame because real agility comes from adherence to disciplines that the originators of the Agile Manifesto were good at.   Deployability, testability, maintainability, reliability are all mandatory for true agility.

    One thing I have learned is the following two approaches take about the same amount of time

    1. Think carefully about requirements, spend time discussing the context of requirements, develop on the basis of the richer context
    2. JFDI, bodge it out.

    In step #1 you will probably have a PM, delivery manager, stakeholder screaming at you for delivery.

    For step #2 the screaming comes after delivery and the inevitable management bonuses have been paid.  And it continues.  You can't polish a turd but you can role it in glitter.

     

  • WOW, I hear you! My recently retired former supervisor was the biggest advocate to maintain technical debt that I've ever known. We have an old application which is horrible to maintain and is now becoming so old that updates to Windows is making it progressively fail. I asked that former boss if I could rewrite it. His answer was, "NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!" It was his firm belief that all developers hate all other developers and all we want to do is rewrite other developers code.

    Nothing could be further from the truth.

    Often all I want to do is upgrade the frameworks a software system relies on, but there was no way I could convince my former boss of that. He demanded that we leave all our software based on whatever out of support framework it was originally written in. Consequently, our technical debt is very high.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • A good rule of thumb that I've often used when creating something new is to ask myself, "will I be able to understand what I've done when I look at it six months from now?". If the answer is NO, then I'm not comfortable deploying it.

    Complexity is often unavoidable but with a good design and useful comments in the code, it can be somewhat mitigated IMHO.

    • This reply was modified 2 weeks, 1 day ago by  netmikem.
  • This was removed by the editor as SPAM

  • This was removed by the editor as SPAM

  • netmikem wrote:

    A good rule of thumb that I've often used when creating something new is to ask myself, "will I be able to understand what I've done when I look at it six months from now?". If the answer is NO, then I'm not comfortable deploying it.

    Complexity is often unavoidable but with a good design and useful comments in the code, it can be somewhat mitigated IMHO.

    Sometimes you have no choice, but that's the type of question I ask myself with commit messages and documentation. Why does this do this a certain way.

Viewing 8 posts - 1 through 7 (of 7 total)

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