Looking Back at Software Development Trends

  • Comments posted to this topic are about the item Looking Back at Software Development Trends

  • From a data stand point I see microservices causing as many problems as they solve. The idea of having a neatly encapsulated application and data store that does one thing well is seductive.

    If I liken Microservices to an organ in the body then data is the blood supply.  I'm not sure that point gets across enough.  The most painful pieces of software that I've had to maintain have been those where there are poorly drawn boundaries and confused responsibilities.  In my experience this is as devastating to a microservices architecture as it is to a monolith. The microservices version tends to mask the problems.

    I'd agree that customer outcomes need far greater prevalence.  When a project is delivered its success is trumpeted from the roof tops but that is celebrating delivery success not customer success. The idea that something so many people across the enterprise have had a hand in did little of benefit for the customer would go down like a lead balloon.

    Software and database design are skills.  If I can liken it unto furniture manufacture then many of us can do a great job assembling flat pack furniture. Some of us could make a decent job of copying a flat pack pattern or extending it slightly. Far fewer of us could design an innovative piece of furniture, an ingenious expanding table or new type of hinge.

    I perceive a lot of tech choices and architecture as attempting to solve problems that are of our own making. Quick fixes that don't last.  Some of the best tools are actually the simplest ones.

  • This topic interests me intensely. I've been reading about software development trends for many years, with a view to improve myself and to suggest better ways for those I work with. However, in my current work environment, it's a real mixed bag. I see a political battle ahead, as those who want to use more modern project management and processes vs. those who want to do everything "as we've always done it since the '70s". I really don't know who's going to win this one.

    • This reply was modified 4 years, 2 months ago by  Rod at work.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Whoever signs the checks usually wins.

  • This was removed by the editor as SPAM

  • This was removed by the editor as SPAM

  • Rod at work wrote:

    This topic interests me intensely. I've been reading about software development trends for many years, with a view to improve myself and to suggest better ways for those I work with. However, in my current work environment, it's a real mixed bag. I see a political battle ahead, as those who want to use more modern project management and processes vs. those who want to do everything "as we've always done it since the '70s". I really don't know who's going to win this one.

    After almost 2 and a half years later, I have to ask (I'm always curious about such things)... if you had the authority to change just one thing that the company has been "doing since the '70s", what would that be and why would you change it?

    And, nope... just to be sure, I'm not planning a conflagration about this.  I'm seriously and honestly curios.

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

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

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