• @ChickenLadyLovesLife@lemmy.world
    link
    fedilink
    English
    141 year ago

    I had a coworker who was big into TDD. He was using it on a disaster project that was way over budget and long overdue. I was sitting in on a meeting between him and the client when he tried to defend the project’s status by saying “you don’t understand - we’ve written six times as much test code as actual code!” The client almost punched him.

    IMO it doesn’t matter what methodology you use if a) you don’t have the ability to understand what the client actually needs, and 2) you can’t code your way out of a paper bag (or to put it more technically, if you over-architect your solution and then can’t solve all the self-inflicted problems you run into).

    • @fiah@discuss.tchncs.de
      link
      fedilink
      51 year ago

      a) you don’t have the ability to understand what the client actually needs

      the client doesn’t understand either. This I have had to learn to accept and not blame the client for, it’s OK and we’ll figure it out together

      b) if you over-architect your solution

      we can’t figure out what we actually need by overarchitecting something to death. If and when you find you’ve coded yourself into a corner because you didn’t architect well enough 6 months ago, then congratulations it seems like what you’re doing is good because you’ve made enough progress to actually need a better architecture

      obviously I’m oversimplifying and people more experienced than me understand better how to walk the tightrope between unmaintainable spaghetti and an overengineered mess, but me, I try to keep shit as simple as possible because you never know