Software has a problem.

OK, it has many problems. I’ve already highlighted one of them. But this is another important one.

The problem is that software—all software, with no exceptions—sucks. The reason for this is multifaceted and we could spend years and years arguing about who has the larger list of reasons, but in the end it boils down to the proverbial shoemaker’s children: Our development tools are the worst of the worst in software.

  • @ttmrichter@lemmy.mlOP
    link
    fedilink
    12 years ago

    Oh irony of ironies, today is a perfect example of what I’m alluding to in the blog. I was unable to post this all day today because the recent server update caused some problem with a component that Lemmy uses for pictures.

    Software sucks.

    Note, I’m not trying to drag Lemmy’s programmers here. They can’t help the fact that the software tooling landscape is a wasteland. They’re the victims in this, not the perps.

  • @ree@lemmy.ml
    link
    fedilink
    12 years ago

    This article lack the answer to a fundamental question. What’s the definition of “software sucks”?

    Then it start with " the bike shop has good tool" . does it? There are obvious limitations to the tools available, some breaks wayyyy too easily, there are competiting standard , backward compatibility issues, sometime the bike break instead of the tool, ect.

    Moreover bike mechanics do not have the skill set to build their own tools from the ground up. Programmers do.

    It seems that the author has a romantic notion of programming and the world in general.

    • @ttmrichter@lemmy.mlOP
      link
      fedilink
      22 years ago

      You think most programmers have the skill set to build their own compilers, debuggers, operating systems, etc. from the ground up … and I’M the one with a romantic notion of programming.

      Most people who call themselves programmers think that “full stack” means Javascript on both the server and the client. Think the best way to program is to go to SO and cut and paste code snippets. These people cannot build their own tools from the ground up. They can barely get a CRUD-backed web site up and running.

    • @dragnucs@lemmy.ml
      link
      fedilink
      12 years ago

      The problem is more profound than what the author implies. Inother disciplines tools are made of something else or by an entire discipline. While software is made out of other software.

      For examples, bikes tools are not other bikes. One does not fix a bikes brakes holding another bike in his hands. While a software 005757. So debugging the debugger involves yet another debugger or in the best case, the debugger itself (dogfooding).

      In a bike ship, if my wrench gets bent, I need knowledge in material and heat treatment to make a better wrench. In software, if if my debugger sucks, I need knowledge in debugging software, and guess what,theat debugger sucks more because it is at a lower level.

      Concrete example. I want to build a web app and use my favorite JS framework. Things generally work well and I use the browser own developer tool to debug. If I see something wired, I need to get down a level and see what webpack or any processing tool I use does to my code. Which is the same process of debuging juste a bit different.

      • @ttmrichter@lemmy.mlOP
        link
        fedilink
        02 years ago

        The tools used in forging steel tools are made by forged steel. There are different skill sets even in foundry-oriented metalwork.

        I know this goes against the grain of software developer ego, but there are actually very different skills involved in various types of software, and someone who can churn out a CRUD-backed web page at the push of a button (often almost literally) is not going to be making an optimizing compiler anytime soon, while the compiler writer may look at the utter screwed-up state of web programming and recoil in horror, not knowing where, even, to begin.

        It’s great for the ego to say “it’s all software, so because I can write a <insert trendy web framework here> app, obviously I can write an operating system too”. But it isn’t true.

        • @dragnucs@lemmy.ml
          link
          fedilink
          12 years ago

          While what you are saying is true, I disagree because forging steel is not performed for the sole purpose of forging steel. Forged steel, while being the end product of some factories, it is never meant to stay like that, but to be further processed. At least cut in sheet and soldered somewhere. And honestly making a sheet of steel is much simpler than making a wrench. And the order of complexity magnitude between making a sheet of steel and a wrench is certainly not the same as making a compiler and building a website with Go/Node/PHP or anything.

  • Helix 🧬
    link
    fedilink
    02 years ago

    This is mainly software for hardware and driver development. Yes, it sucks. The routing software and proprietary tooling from all the IC manufacturers suck, too.

    It doesn’t surprise me the author bought stuff for thousands of monetary units and it was still shit.

    Weirdly enough, I found that the Open Source variants of said software (e.g. KiCad or the PlatformIO IDE) are way easier to use and more stable than their commercial counterparts.

    If the author spent the same amount of money on FOSS tooling, it would be better for them and everyone else.

    • @ttmrichter@lemmy.mlOP
      link
      fedilink
      -12 years ago

      F/OSS is not the panacea its advocates claim it to be. I mentioned collecting bizarre compiler bugs. GCC has a huge presence in my collection.

      And this ignores the fact that F/OSS often has no presence whatsoever in entire industry swathes. F/OSS, for the most part, with some exceptions, lags behind the technology curve when it comes to bleeding-edge tech. This is sometimes the fault of vendor shenanigans (I’m looking at you here, Altera and Xylinx), but often it’s just the problem of a very specific problem domain with very few eyes willing to work on it as a hobby.

      • Helix 🧬
        link
        fedilink
        1
        edit-2
        2 years ago

        often it’s just the problem of a very specific problem domain with very few eyes willing to work on it as a hobby.

        Why do people always confuse FOSS with hobbyist software? There’s lots of commercial FOSS out there, some even with a sane ecosystem.

        For example, the PlatformIO IDE is part of a larger, commercial ecosystem. Open Source allows a code and architecture audit before spending a single cent.

        • @ttmrichter@lemmy.mlOP
          link
          fedilink
          12 years ago

          Because a lot of it, even when “commercial” is hobbyist-grade at best.

          PlatformIO being one of the ones I’d place there, incidentally. Failed out of the box for me (where “fail” involves “crashing”) when I tried it, resulting me in spending more time debugging my tools than my own code. Which is exactly what I rail against in this article. Even this reeks of hobbyist work:

          Multi-platform Build System without external dependencies to operating system: 50+ development platforms, 1000+ boards & dev-kits, 20+ frameworks. Arduino and ARM mbed compatible.

          That focus on “boards” and “dev-kits” is basically useless for people who, you know, are making their own hardware. (Like my employer.) By the time you navigate through all that (often poorly-written and invariably poorly-documented) crud it’s actually cheaper, in terms of development time, to write it from scratch in-house.

          I genuinely gave PlatformIO a try for a work project. I had to ditch it and replace it with a hastily-assembled ST HAL-based from-scratch project to get it done in time for the test cycle. It’s simply not suited to the use cases I have both because of the crashing issue and the way hardware support enters the picture (which revolve around 100% custom hardware in our shop).

          Had the first issue not been there, I might have had more patience for the second one (and vice versa), but the two together made it a show-stopper and added to the long list of shoemaker’s children.

  • @roastpotatothief@lemmy.ml
    link
    fedilink
    02 years ago

    I don’t think it’s the right general solution, but the solution to the specific problem framed by the OP is software as a service. You get a free trial, then you pay monthly, as long as you continue using it. So the developer is incentivised to make the software work properly.

    • @ttmrichter@lemmy.mlOP
      link
      fedilink
      12 years ago

      Software as a service has its strengths but has more weaknesses from the perspective of someone trying to base their own business model on it.

      If compilers were SaaS, for example, there’s no way to make stable, confirmed firmware. (Hell, it’s hard enough to do that when you in theory control your own software!) For some sectors (like the sector I work in) this is an absolute necessity. You can’t have a sudden change in the compiler happening out from under you making your firmware’s hash value different and thus requiring another (expensive!) round of verification.

      And this doesn’t even count the problem of using a third party’s continued existence in the core of your own business. My employer owns the IAR seats that it has. (Does IAR suck? Of course it does! Have you not been paying attention!? 🤣) If IAR go out of business tomorrow, we can still do our work because the software is on our machines. If we SaaSed our tooling, we’d be fucked when a single vendor goes under, along with their servers.

      If there could be some way to guarantee stability of SaaS, both in terms of release management and in terms of persistence beyond the scope of the company offering it, SaaS could very well be a way for companies to be forced into upping their game, but I personally can’t even envision the solution to those two critical problems.

  • @blank_sl8@lemmy.ml
    link
    fedilink
    -12 years ago

    Two dimensional, one dimensional…you can make a bijection between Z^2 and Z, so who cares? There is still structure in one dimension.