Do Developers Benefit From Fewer Choices?

Posted by EditorDavid

on Saturday April 09, 2022 @11:34PM from the freedom-from-choice dept.

• ›

  by Arethan ( 223197 ) on Saturday April 09, 2022 @11:41PM (#62433326) Journal

  Please stop us from accepting every-language-under-the-sun. There are many, and trying to support them all is an absolute nightmare. My motto is, if you want to use an unapproved language, you'd best develop your own internal users support group, so you can all solve your own integration problems. If your thing manages to go into production (failure on your manager, but I digress), be prepared to spend the time/money to constantly fix it as the company core infrastructure continues to move forward while decidedly leaving your hobby behind.

  • Re:

    And every source control scheme, flavor of scrum, ticketing system, and configuration management tool, to name a few of the already solved problems which waste months and years of work integrating with alternative solutions.

    • Yes and no

      Python was a breath of fresh air when it was new in part because there was only one idiom for doing anything, even white space, and so everyone could read and understand everyone's code. Alternative idiomatic features and deprecations crept in and at first these did augment the expressiveness and ease of use . And unlike say C++ these where more thoughtfully organized. Rather than a toolkit of oddly shaped wrenches. But now we've reached a point where it's impossible to decipher other peoples code. Time t

  • The problem is kids chasing the latest fad without giving a moments thought to the future. Well, that at the middle-aged guys chasing trends.

    Of the the most important, yet tragically overlooked, factors when choosing a language or other tool is stability.

    When I talk about stability, I have three factors in mind:

    1. It needs a good history. It should have existed for a while, 10 years at least, with good reason to think it'll stick around for another 10.
    2. It needs to have more than one implementation. You really don't want to get stuck trying to support a code base built on some vendors proprietary technology after they've abandoned it. I'm looking at you Microsoft and Google. Open source is nice, but it's no panacea. You need to ask yourself if you're willing and able to manage the project if the key maintainers leave.
    3. Changes should be infrequent and come with plenty of warning. Standards bodies are helpful here... most of the time. (Some of them seem to think that they're not doing their job if they're not making frequent changes, no matter how stupid.) The good ones know that their job is to resist change and avoid breaking things when it's unavoidable.

    It's worth taking a few minutes to think about how your current preferred tools stand in light of these. I've tossed out things that I personally liked and haven't had a single regret yet.

    • Re:

      Does c# fit into that category?

      • Re:

        Ok replying to myself but I've forgoten something important when it comes to c#, Ignore microsofts apparent in ability to pick a GUI framework and stick with it, since the advent of.net core (later renamed to just.net) there are alternatives out there

        • Re:

          C# is a little more complicated because there are extra things to worry about. I'll try to answer as best as I can, though I'm not a C# expert.

          1) C# has been around a for more than 20 years now and while it's likely to stick around, Microsoft has abandoned.net framework. Fortunately...

          2)... There are multiple C# compilers and multiple.net framework implementations, though not everything is supported. The Mono project is the big one here, which is now also owned by Microsoft. It would be nice to have m

          • Re:

            Huh?
            
            1).net framework has not been abandoned, far from it (https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework)

            • Re: FFS YES PLZ

              It's not abandoned in the sense that it will still be supported on windows for maybe another 5 years, and then after that any major new versions of Windows probably won't support it, but meanwhile it will receive security updates until say Windows 11 is end of support.

              However, there will no longer be any feature additions as of the release of.net 5. So things like.net MAUI, which is basically going to replace/succeed WPF in the long run, won't ever see the light of day in.net framework.

      • Re:

        > Does c# fit into that category?

        It violates the
        - "good reason to think it'll stick around for another 10", Silverlight perhaps the example that hurt mostly those who used it. There is really no guarantee. When Microsoft decides to end it, it will not continue. (yeah, some hobby project will still run the Mono but it will be just a sad shadow of it)
        - "It needs to have more than one implementation.", only one full implementation

        • Re:

          .netcore is open source, so your comment is moot.

      • Re:

        At work just the other day in our group, someone asked for a Devl Joke. I forgot it, but the the punch line was "c sharp". It just got quiet. I then asked, does anyone here know what "c sharp" is. Only me and the person who who said the joke knew it was "c#". I guess that was was the real joke.

    • This is why I got into Perl.

      It had existed for a while, and was well established.
      
      Then I got so sick of it I just didn't care anymore.
      
      I feel myself heading in that direction with Python.
      
      Choice is always good. We are not children.

    • Re:

      All of these reasons are why I prefer Common Lisp even if Racket is all the rage these days. And probably a subset of C++20 over Rust, at least for now.

    • Re:

      Something I think should fall under this idea of stability is 'fit for purpose, does what it says on the tin.'
      You want the tech to actually do the thing you're trying to use the tech for. The big example I would bring up is ZFS. When ZFS was brand new, people were proselytizing about as hard as I'd ever seen tech proselytized. The problem came when I looked into the implementations of ZFS and found that all of the implementations were totally lacking the features that it was being sold on. ZFS did not do i

  • Re:

    Why are your architects, tech leads allowing you to use unapproved languages?

  • Re: FFS YES PLZ

    I personally prefer to use Rust for everything. Once you get past the initial learning curve, it's a really easy language.

    At my work we use Java mostly, because we maintain a vendor product that is based on it. We're not really a software development team though, more of an automation team (and thank god it's not fucking RPA shit.) Part of that means we already have precedent of calling CLI tools in many cases for integration with other vendor's products. So a lot of times I'll write something in Rust that

• Let's all standardize on using the JOVIAL language. It's got the math stuff from IAL, but it also has plenty of nifty features for systems programming and can drop to bare metal if required.

  • Re:

    Instruction unclear; my homebrew washing machine is now ITAR-restricted.

    • Re:

      How can a washing machine ever get ITAR restrictions? Either this is a joke, or you have a rather novel design

      • Re:

        Does your washing machine use a controlled munition, like encryption? You know, a web server.

        • Re:

          The tub spins ultra-fast and thus can be used to purify uranium.

        • Re:

          Hmm i forgot thst angle, fine so I'll ship the webserver as an jso to be diwmloaded from an eu shist rhus no crypto code leaving the us, just butn the immage to a emmc and plug it into slot a

  • Re:

    I vote for either TACPOL or PL/1

    • Re:

      I really liked PL/1. Of course, you needed the full languages, the subsets were a real pain. But I don't think it could compete with C++. What's needed is a real Python compiler, with optional typed variables to allow optimization. Cython could develop into that. (FWIW, I really, really, don't like Rust, but Vala and D have lots of good points.)

      (OTOH, I think the original post was trying for the worst language that wasn't intentionally bad, and for that I'd suggest APL. The original version, that requ

      • Re:

        IBM made a couple of models of teleprinters that used a Selectric type ball. The APL\360 language character set included a number of backspace/overstrike combinations. To emphasize its character set edginess, the backslash was deliberate.

      • Re:

        I was really just going for something old that could be used widely. PL/1 is another excellent candidate for that. Being something of a whippersnapper, I use C++ a lot. Coworkers give me grief: "Why don't you use python?", but I maintain that static typing and compiling to native machine code are good things.

• They start with something known from market research, which is fairly objective. Then they say, "It turns out," which normally would followed by an additional objective claim. But nope. "writes some guy." That's just an opinion. Nothing "turned out" to be a particular way.

  Do companies buy software because they were browsing around? Does the personal satisfaction of the purchasing agent matter? Or there is something else going on with software; is there a concrete problem that software is intended to solve?

  • Re:

    Yes, but it's worse than that. Executives at my company often come to me after being cold-called by some random software salesperson. "Do you think we can make use of this software? Would you please join me for a demo so we can determine whether it will work for us?" We developers already know the answer. No, it's just another BS solution looking for a problem to solve. Sometimes we can talk the execs out of buying the "solution", sometimes not.

    • 1 hidden comment

    • Re:

      So perhaps it is software salespeople that are harmful to companies, rather than software choice?

      • I wouldn't say that. Choice is good. Making wise choices is better. Putting non-technical executives in charge of technical buying decisions...not so good.

        • Choice comes first.

          You can't make a wise decision if you're not allowed to make the decision in the first place.
          
          Being an employee will always suck.

          • Re:

            There's no reason to believe that, if choices were limited, the (few) available choices would be wise ones.

      • You want to avoid any software that has salesmen associated with it.

        You especially want to avoid any software sold by salesmen who target non-tech executives.

        Oracle is the worst offender. I despise them more than Microsoft.

        • Re:

          Software without salesmen tends not to last long enough to be useful.

        • Re:

          Yea Oracle has a lot to answer for, Uncle Bob has something to say [youtu.be] about that

    • Re:

      When I'm asked questions like that, I ask what problem they have that they're trying to solve with this. You can make use of almost anything, after all, but it's usually a waste of time.

      • Re:

        You are lucky indeed if you have executives who would pause in their enthusiasm for some "miracle" product just because you asked what problem they needed to solve.

        Yes, that is absolutely the right question. When choosing a product (or language) one should start with identifying the problem to be solved. Then based on the requirements, choose the best tool for the job. Not the other way around.

  • Re:

    Reminds me of when I asked the group at work that works on our Confluence Wiki for a simple calendar widget... the same one I used in Confluence that the last gig. Apparently, it's a "Premium" feature and I was told no.

    A fucking calendar is a "Premium" feature. Yeah, that answer did fill me with a lot of hate as far as using Confluence.

    • 1 hidden comment

    • Re:

      I took a contract back in the early 2000's to add a feature that allowed users to print the reports their product generated. This feature was sold to their customers as an $800/seat add-on. I'd say I should have changed them more but they never paid my invoice.

      I just don't have that kind of larceny in me.

      I've often wondered how many of their clients figured out they could just copy/paste the report into wordpad...

  • Re:

    > Do companies buy software because they were browsing around?

    Yes. Managers or architects get impressed by an article or a demo and don't understand the limitations of a new toolkit. After such projects fail or get bogged down, my people get called to clean up the mess.

    • Re:

      Yes. But let's not leave the developers off the hook so easily. There is a lot of evangelism for developer's favorite tools, and many agitate for them. In the one field I'm involved in but don't have enough power, which is development of Emergency communications for Radio, there is so much evangelism and multiple approaches and parochialism that failure is pretty common, as people end up having to learn several processes, and non-computer types end up getting overwhelmed with whatever new fangled system som

• The mere fact that he frames this in terms of consumers shopping for things pisses me off. That tells me what he thinks of us. We're suckers to sell things to!

  The fact that he weren't aware/bright enough to frame this as the well-known "using constraints to unleash our creativity" tells me that they're not even aware enough to listen to. Um . . . to read.

  Matt Asay! Who cares what Matt's Ass says?

  • Re:

    Meh. Incomplete edit: change from they to him. Fooey!

  • Someone's gotta buy all those toys!

    Scanning this overlong cut-and-paste from a longread, I notice it is all about the tools you can buy. This guying is to reframe how "we" (really middle management) thinks about that. With as ultimate goal, "buy our stuff".

    Putting that frame aside for a moment, if "developer productivity is a must, not a nice to have", it's perhaps time to own up to having fucked that up in the workplace for political status game reasons. For verily:

    It's been noted that developers work best in silence for deep concentratio

    • 1 hidden comment

    • Re:

      What's best depends on what you're doing.
      OTOH, there needs to be limits put on that, or you (well, I) spend too much time trying this language or that to see what fits best. For what I'm currently doing I've settled on Python, but I only did that after trying C, C++ (with various toolkits), D, Java, etc. I'm finally back to Python, which is where I started. The deciding factor is it's a language that I can write on one OS and have it run (including database access) on another without recompiling. (Yeah

      • Re:

        We all will. There is a saying in the art world that creativity needs limitations. Programming is no different. Imagine a room full of programmers where any one had veto power over the language used for a project, and they were all evangelists for their favorite language.

    • Re:

      Agree with the point that if you are wanting to improve developer productivity give them silence and offices with doors first like the research has proven out. There is over 100 years of research on human performance that is ignored by companies. Start there.

      I can see the point on restricting languages too as it can go too far into there always being some subset of the developer population in learning curve mode if you have too many. We recently did that and I think there are like 7 or 8 approved languages

  • Re:

    That's not the point, I'm certain.

    The point is, at some point, more choices becomes more of a problem than a help. The food aisle is just a good analogue for that.

    If you have ten tools to choose from to do the exact same task, and someone thinks adding ten more is a good idea, and now you have to learn those ten more tools, the tools end up becoming the task. Fragmentation, and pointless fragmentation.

    • Re:

      The point is, like I said, "using constraints to unleash our creativity." But the author is too dim to realize we're creators, makers and not just shoppers.

• • Re:

  • Fast, cheap, good.
    Choose two.

    That is accurate for many things in life, but not software.

    For software, quality is often negatively correlated with price.

    • Re:

      The correct quote is "choose no more than two". You can certainly get all kinds of rubbish which is none of the above, or only one.

      • Re:

        You gotta pay more for the correct quote.

    • Re:

      Especially if it's a major consultancy providing software services to public bodies for some reason...

    • Re:

      Another person who had to use Oracle?

  • No

    You can get fast, cheap, and good if you have the right people.

    • Re:

      And how are you going to get (and keep) the right people? In most cases, the "right people" will quit if you don't pay them well - and if you do pay them well, it's no longer "cheap".

      • Re:

        > and if you do pay them well, it's no longer "cheap".

        I think that 10 good people with 10x salary make your project cheaper than 100 average people. Even if you exclude maintenance.

      • Re:

        Exactly. All three is unsustainable. If your business is based on attempting all three, those low paid programmers you are abusing to get it out fast and good will end up leaving.

    • Re:

      Fast, cheap, good, the right people.
      
      Choose two.

• Lets start with retail, the only reason less could be better is because the consumer can't gauge the difference. Product marketing has gotten very good at making even crap products look like premium. If the consumer is unhappy afterwards it's because they were fooled.
  Think I'm wrong, no one every said, too many choices at a restaurant. No one ever said they have too many different kinds of restaurants in their neighborhoods. No one ever complained that video rental stores have too many choices. No one

  • Re:

    That's actually the classic example of paralysis of choice. I've fallen for it too, with, "Do I want X? Oh, but Y sounds good! OOOH! Z!!! Shiny!!! Dammit, what do I want to eat!"

    • Re:

      > Dammit, what do I want to eat!

      If you don't know what to do, you do what all nerds do in such a situation. Use math to solve it.

    • Re:

      AC might like a lot of choices, but too much choice in eateries can be a real problem. I've seen people freeze up at fast food restaurants, it seems to be a fear of making a "wrong" decision.

      Nothing like being stuck behind someone who can't decide on the product.

      • 1 hidden comment

  • Re:

    "[N]o one every said, too many choices at a restaurant."

    Actually, yes, they have. Frequently. Having too large a menu is considered one of the classic mistakes in running a restaurant. It greatly increases your costs while providing not nearly enough increased revenue to pay for it. In fact, in some cases, it can decrease your revenue, precisely because of the phenomenon under discussion here.

    • 1 hidden comment
• and the weak development tools, languages, environments, platforms and fads usually fade from the picture.

• • Re:

    you're a 6 digit though. basically a newb:)

    in regards to the story, i think restricting choice forces developers to either get creative to solution within the restrictions... or it forces inefficient use of time and subpar results when better options exist.

    really depends on the quality and choice of what you are limiting them to.

    • Re:

      you're a 6 digit though. basically a newb:)

      The "UID dick measurement" contest is back!

    • Stravinsky allegedly said something like:
      If you tell me I can compose anything I want I don't know where to start, but if you tell me it must be for tuba, triangle, and bass drum, and must last for 5 minutes I can begin composing immediately.

      In other words, at least in the arts, constraints - as long as they are not too restricting - can be very helpful.

  • Re:

    You seem to love the cloud. Well, for some applications, I suppose that's reasonable. But for many it's a really bad choice.

    • Re:

      I actually agree, however context matters. We run a small business, and the security and compliance offerings. also, managed certificates and platform updates are a very nice bonus. all things considered, its just a matter of time. Is it worth my time to manually go install platform updates, check certificates all the time, monitor logs, and all the other routine things. I'd absolutely love to have a large enough budget to include having dedicated people managing all of those things, and i could hav

• ...introducing more choices! Brilliant! I mean, instead of just using specific tools and frameworks, now you also get the choice of using a bigger framework that consists of specific tools and frameworks! Oh, but that's not all: you get to choose between multiple different ones of these bigger frameworks and, in all likelihood, between different paid options for each, increasing the number of choices practically exponentially! Not to mention that each choice will almost certainly have multiple different kin

• Short one: never.
  Long one: read the Art of computer programming.

  • Re:

    Allow me to add my favorite book on programming, which sits on the shelf next to Mr. Knuth's opus.
    the dot, by Peter H. Reynolds. ISBN 0-7636-1961-2.

    If you fail to comprehend the lessons in Mr. Reynolds book, then perhaps programming isn't for you.

• If you are a true professional, it won't matter to you if your employer uses technology X, Y or Z, or if you're restricted from using A, B or C. You'll have the capacity to adjust as required, because that is what professionals do. Being a professional also makes you accept that, in the end, it is not your project, and that you should have zero expectations regarding ownership, decision making or using the platform owned by someone else to experiment, and you understand that this kind of freedom and control

  • Re:

    This will rapidly devolve into a "No true Developer" argument though.

    A lot of developers in here. And Slashdot is about the worst "Ford versus Chevy" environment I've ever been in.

    Anyhow, if you have that ability to adjust and quickly learn whatever environment and programming you are thrust into, I'm impressed and that's good. But that might be the exception that proves the rule?

    • Re:

      "I never make exceptions. An exception disproves the rule." - Sherlock Holmes, The Sign of Four

• Code is just a by-product of the software development process, the real value is in the concepts and specifications that are created in it.

  This is something many people have understood in the last few decades. Good software design may be done rather efficiently with a set of tools, but it doesn't require those tools to be used. Instead good software design separates code from data and makes the code easily replaceable. In fact one common trope in C programs is to put the logic into constant data structures in your program and to only write a small program that will work on those structures with your data.

  However in some cases the problem of having to many choices can be bad. A good example are language constructs in programming languages. It's a good idea to write your software in a way an inexperienced programmer can read it. Any new language feature you use adds additional mental load on the mind of the person that needs to read it. For example in C avoid if's where there is just an integer in the condition clause. Avoid ++x and x++ operators, particularly when using the value. Avoid non-standard for loops. Put variable declarations where you first use them an _not_ on the start of your block, etc....
  It helps to limit yourself in order to make the resulting code easier to understand.

  • Re:

    Code is far more important in practice. Code is the tangible thing.
    It is to an extent the very specification and concept you speak of, just done at a very low level.

    However, there is another big reason why 'code' should be thought of as the end product, and not just the by product. Software development is much more than just writing code.

    Programming languages have a lot of supporting tools. From IDEs, security scanners, build integration, packaging, monitoring tools... Build a new language, it will be years

    • Re:

      "It is to an extent the very specification and concept you speak of, just done at a very low level."

      That's a wonderful little nugget of thought as it also means that there will be no bugs. Every "bug" will be part of your "low level" specification.

      I've worked at a company where my boss had exactly the same idea. This was at a VoIP company. The problem only start when you have to interfere with other people who don't see your code as specification, but instead things like RFCs or "common sense". With code wr

• This means that that free box of doughnuts on Friday morning won't be the usual variety pack, but instead be all pink frosted. The one you hate

• Has the author not heard of Technical Architects, who define the tools Dev use?

  • I'll be joining you soon.

    Burning my karma because I just can't keep my mouth shut.
• As a devops dev, I routinely search for JS, and Python libraries to accomplish X all the time. Many of them appear to be a grad students proof of concept and abandoned. It takes time to find a maintained, and hopefully mature library.

• Of course they choice effect is rampant in IT, especially Web development. Every odd month there's a new fad. Ever since they ruby on rails hype (right here on slashdot, 14 years ago... f*ck in getting old) and the VDOM craze started I've been actively working against the choice effect. I'm still using LAMP to this very day and can't wait until I see docker and node crowd go the way of rails. Bring comparatively conservative in my field has helped me keep my sanity and stay on top of things in PHP. Very helpful. I also see to it that my trainees stick to their PL of choice if it's not totally obscure or proprietary. One of them just started of with Python and is eager to get into JavaScript. I told him to chill and stick with Python for now. Python alone is a whole world unto itself, he'll have 10, years of things to discover there.

• I've seen many comments here, many of which I concur with. However, working in the development consulting world for 40+ years, here's my two cents: (highly simplified)
  
  1) In a small shop (less than 40 developers), they tend to choose and remain with a standard set of tools, languages, libraries and operations/management tools just by inertia and a set of "principle" architects that provide the guidance. These "principles" can let things get out of control as they find and propose new technology and ad