• ExtraMedicated@lemmy.world
    link
    fedilink
    English
    arrow-up
    104
    ·
    1 year ago

    3 months ago:

    “Can you comfirm that each user account can have no more than one of these entities?”

    “Yes. Definitely.”


    Today:

    “Oh by the way, we have some users who need to have multiple entities. Can you fix it?”

    • jadero@programming.dev
      link
      fedilink
      arrow-up
      52
      ·
      1 year ago

      I eventually learned to never trust any restrictions on the user.

      I quickly learned to make sure everyone had a copy of decisions made, so that I could charge by the hour for changes. I eventually learned to include examples of what would and would not be possible in any specification or change order.

    • Kalash@feddit.ch
      link
      fedilink
      arrow-up
      34
      ·
      1 year ago

      I’m in the exact same boat right now.

      Also this change from 1:1 to 1:n entity was like one “minor” feature in a rather larger list of feature requests. It so far has caused more work then all the other features combined.

      • AggressivelyPassive@feddit.de
        link
        fedilink
        arrow-up
        19
        ·
        1 year ago

        And months later you’ll find out, that your change completely fucks over some internal optimizer statistic and causes the DB to turn into lava.

        I definitely don’t know that, because of several hour long outages and millions of lost revenue.

      • sip@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        this is ongoing now. Our “creators” were supposed to be “matched” for a “job” based on “skills”, not “skill”. pure chaos

      • sip@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        yea, but it stops being fun when they say it’s a bug and it’s always supposed to work like that.

        • jet@hackertalks.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Then it’s a valuable lesson in writing your client contracts and your work change order templates.

          If you bid per project you need to have clear milestones and sign-offs. If you bill per hour then it’s not issue.

    • AggressivelyPassive@feddit.de
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      1 year ago

      That’s why you get everything in writing. No change without detailed description of what you’re doing and a written reply stating that yes, this is what they want. Otherwise you’ll be in a constant refactoring treadmill.

      • Ikiillpplalot@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        I’m working for a big company and our end-user has a lot of ideas of what features he wants. The only issue is that he changes his mind at the end of each sprint or in the middle of it. I am happy he has ideas for making the work more efficient because at the end of the day that’s the major point of our work, but he can’t lock down a deliverable. We have a business admin that’s supposed to work out the actual work we need to do but this end user both won’t take no for an answer for his idea and won’t stick to his own script. I’d describe it less as a feature creep and more as a bunch of lateral moves and shifting goalposts that doesn’t always amount to something better than the first interation yet it’s still somehow a major blocker. Not only that but the big picture ideas get lost in his own plans and it becomes all about the small things he didnt articulate when I present the work.

        It’s getting pretty frustrating.

        • blackstrat@lemmy.fwgx.uk
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          Solid change control. I’ve seen so many project come undone through lack of change control. You can only develop with stable requirements and changes to requirements should come with a cost. Without it it’s basically offering unlimited development forever, often on fixed fee contracts too.

  • fsxylo@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    23
    ·
    1 year ago

    It’s a good thing I’m a hobbyist so that I can avoi- hmm, now that I think about it this feature could be really cool and shouldn’t take too long to implement…

      • potoo22@programming.dev
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Spouse at 7:00 AM: “Why do only some of the house lights work and there’s no hot water?”

        Me: “You know that quick fix I was working on last night. Well, umm, one thing led to another aaaand… Umm… Just so you know, your phone is using mobile data because the wifi is out.”

  • malloc@programming.dev
    link
    fedilink
    arrow-up
    17
    ·
    1 year ago

    In consulting, that’s called “after work”. Got to pump those billables

    Honestly though, unless it’s a feature that is completely outside the domain of the application. If you have to re-write your entire app then your app was probably dog shit to begin with

    • Doc Avid Mornington@midwest.social
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      To be fair, it said “an enormous amount of code”, not “your entire app”, but yes, the ability to add unexpected new features or make focused changes without touching more than a minimal amount of existing code is a very good smell metric of code quality. The problem is that for every dev who understands how to program like that, there are at least five, probably more like ten who don’t, which means most of us are working on teams that produce a blend of clean code and, as you say, dog shit, so the feature request that requires stirring up all that shit is out there waiting for us, like it or not. The best we can do, when it hits, is try to at least improve all the shit that we touch in the process. Maybe some of it can become compost, I dunno, the metaphor breaks there, gonna have to refactor the metaphor.

  • douglasg14b@programming.dev
    link
    fedilink
    arrow-up
    14
    ·
    1 year ago

    If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.

    Your frontend will always churn, that’s the nature of the job.

    • vivadanang@lemm.ee
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      Your frontend will always churn, that’s the nature of the job.

      Yep. The trick is to be gone before anyone finds the gross stuff needed to make it all work.

  • ChickenLadyLovesLife@lemmy.world
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    My favorite thing was having to rewrite an enormous amount of code to support a new feature because the original architect originally wrote an enormous amount of code in anticipation of supporting a new feature like it.

  • Sigh_Bafanada@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    We just need to change one field into an array, so that users can be linked to more than one location.

    We estimate around 400 hours work.

    • vivadanang@lemm.ee
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      We estimate around 400 hours work-

      In order to analyze the problem, inform stakeholders and a allow for a brief period for outlining the next potential steps to be decided by the steering committee. Once there, we can talk about allocating developer hours to enabling the resolution and it’s required upgraded dependencies. See my previous estimate sent 2/7/2018.