• itkovian@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    1 day ago

    This blog summarizes what I have felt was wrong with software development. Managers tend not to understand that software development management is not really the same as planning a construction project. Individual lines of code and individual features of a software can be cheap, but complexity can ramp up really quickly.

    • mushroommunk@lemmy.today
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      1 day ago

      I haven’t read the blog yet but this gets me all the time. I always prefer when managers were former software developers themselves so they understand this innately.

      I can tell you if two strings match in one line of code. If you want any leeway though in the strings matching (say we accept heaven and haeven) we’ve just jumped to a whole separate class with at least three functions and minimum N*M longer compute time plus added complexity in feedback to user (underlining the input or whatever if it’s wrong). But to a regular manager it’s still just “check if two strings match”.

      • MagicShel@lemmy.zip
        link
        fedilink
        English
        arrow-up
        7
        ·
        23 hours ago

        The thing I wish managers understood better is the more exposure a thing has, the more time needs to be spent making sure it’s done right. Spend all the time to architect and get your public API right. One you have consumers, is extremely painful to orchestrate a change if you’ve some something wrong, which will lead to all kinds of tech debt under the hood.

        Then focus on making sure your internal public interfaces are good. By the time you get down to class private implementation I almost don’t care how it’s written as long as it passes tests. (Hopefully I don’t have to say there are a lot of things to care about but they generally are easy to change if you’ve done something wrong.)

        I’m not against agile, but it’s worth pointing out that it encourages the exact opposite — get this piece of functionality working and figure out how to jam in new functionality in a later step. You can’t architect good solutions only looking 2 weeks ahead.