• 0 Posts
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle


  • I agree with most of what you said, but I think I was not clear in my presentation of the domain of operations. I was not speaking to the rewriting of an existing system, but if gathering requirements for a system that is intended to replace existing manual systems or to create systems for brand new tasks.

    That is, there is no existing code to work with, or at least nothing that is fit for purpose. Thus, you are starting at the beginning, where people have no choice but to describe something they would like to have.

    Your reference to hallucination leads me to think that you are limiting your concept of AI to the generative large language models. There are other AI systems that operate on different principles. I was not suggesting that a G-LLM was the right tool for the job, only that AI could be brought to bear in analyzing requirements and specifications.


  • I think he’s missed a potential benefit of AI.

    He seems to be speaking mostly of greenfield development, the creation of something that has never been done before. My experience was always in the field of “computerizing” existing manual processes.

    I agree with him regarding the difficulty of gathering requirements and creating specifications that can be turned into code. My experience working as a solo programmer for tiny businesses (max 20 employees) was that very few people can actually articulate what they want and most of those that can don’t actually know what they want. The tiny number of people left miss all the hacks that are already baked into their existing processes to deal with gaps, inconsistencies, and mutually contradictory rules. This must be even worse in greenfield development.

    That is not saying anything negative. If it were any other way, then they would have had success hiring their nephew to do the work. :)

    Where I think AI could useful during that phase of work is in helping detect those gaps, inconsistencies, and contradictory rules. This would clearly not be the AI that spits out a database schema or a bit of Python code, but would nonetheless be AI.

    We have AI systems that are quite good at summarizing the written word and other AI systems that are quite good at logical analysis of properly structured statements. It strikes me that it should be possible to turn the customers’ system descriptions into something that can be checked for gaps, inconsistencies, and contradictions. Working iteratively, alone at the start, then with expert assistance, to develop something that can be passed on to the development team.

    The earlier the flaws can be discovered and the more frequently that the customer is doing the discovery, the easier those flaws are to address. The most successful and most enjoyable of all my projects were those where I was being hired explicitly to help root out all those flaws in the semi-computerized system they had already constructed (often enough by a nephew!).

    I’m not talking about waterfall development, where everything is written in stone before coding starts. Sticking with water flow metaphors, I’m talking about a design and development flow that has fewer eddies, fewer sets of dangerous rapids, and less backtracking to find a different channel.



  • Perhaps, but don’t forget every god has had to learn a few things the hard way.

    Many will cherry pick or apply self-serving interpretations of your pronouncements.

    Many false prophets will arise.

    Many will rail against your very existence and create competing systems.

    Eventually, you will be considered archaic and replaced by the gods of the new thing.

    Tongue in cheek, obviously, but not too firmly. :j



  • Sort of. I think of the Unix philosophy as being like Lego. Here’s a box of goodies, go crazy. Even Ikea still requires user assembly.

    Most end users just can’t do much with the first and often even get tripped up by the second. What we need is something in between that a programmer can use to quickly throw something together to user requirements.

    Actually, that’s much like what I was doing with Microsoft Access and Visual Basic decades ago. I probably would never have survived in an actual software development shop, but I was kept very busy by a bunch of small businesses that loved the quick turnaround and manageable costs.



  • That’s just the way things work when humans self-organize. There is the appearance of structure at the beginning, because there just aren’t that many people with shared interests. Then as people are unsuccessful in finding the community they’d like (assuming they even looked!) more are created. Then more people come in and mill about and browse and get overwhelmed by the search for a needle in a haystack, so they create more.

    Eventually, some communities reach a critical mass and a bunch of small ones fade away into near irrelevance or disappear completely.

    As far as I know, the only way to put the brakes on community over-proliferation (if that’s even a real thing!) is to add a bit of friction to the creation process. Many kinds of friction devolve into centralization and gatekeeping, so they tend to be avoided in projects like this.

    The only kind of friction that I can see working and gaining acceptance would be some kind of “have you tried these communities?” auto-search during the creation process. Simply asking people to search first is unproductive for two reasons. First, people are notoriously bad at imagining that someone else might have thought of something first, especially when they are only person they know with that particular interest. (I’ve only met a dozen other programmers in 43 years. In my entire life (66) I’ve not met a single person with even a passing interest in boatbuilding, let alone an actual boatbuilder, etc). Second, even if they consider that someone else thought of it first, people are notoriously bad at searching.



  • Absolutely not! I’m not sure anything in any field is so trivially simple that it can be grasped just by looking at it. Getting even minimally competent in anything requires both study and practice.

    The good news is that study and practice are skills worth acquiring, because they are useful in any endeavour.

    The great news is that study and practice are what’s needed for mastery, too, so once you start your journey, you can can continue as far as you want.


  • Not dumb, untrained or not yet sufficiently skilled in this particular area. While you bear some responsibility for getting up to speed, I would argue that it is still their issue if they are not providing the necessary resources. With something like lemmy, you are probably on your own for finding and making use of those resources. But I would be surprised to learn that those resources don’t exist. I haven’t looked, but there must be some kind of documentation written by someone and a community of like-minded people. Maybe even some tutorials.

    That said, some people will always struggle with certain kinds of abstraction or multiple layers of abstraction. For myself, one thing that I find helpful is to view each layer as an API that I’m targeting or a library that I’m using. In those cases, you never really worry about how things get done in the background.

    Do you really have any idea how the keywords that solicit user input work? Not likely. Even if you do, you still completely ignore the fact that you know it while writing a line of code that solicits user input. That is a layer of abstraction that you use regularly without even thinking about it. A good architecture allows the same kind of reasoning about your code.


  • There are a few possible reasons for that, but the main ones are:

    The architecture may be from the rococo (filled with pretty, but ultimately useless and confusing “decorations”) or surrealist (tenuous relationship to reality) schools. This would make it difficult to grasp for anyone but the people involved from the beginning.

    The architecture could be perfectly sound, but for some reason, you are having trouble putting it all together. The most common reason for that is a lack of training and documentation.