Comment by jdlyga

> Low Code or even No Code

I look at the code I'm writing (mostly C# thesedays) and I consider the _information-theoretic_ view of the program code I'm writing, and I see a major problem is that even syntactically terse languages (like C# compared to its stablemate VB.NET) still requires excessive, even redundant code in many places (e.g. prior to C# 9.0, defining an immutable class requires you to repeat names 3 times and types twice (constructor parameters, class properties, and assignment in the constructor body) which alone is a huge time-sink.

The most tedious work I do right now is adding "one more" scalar or complex data-member that has to travel from Point A in Method 1 to Point B in Method 2 - I wish I could ctrl+click in my IDE and say "magically write code that expresses the movement of this scalar piece of data from here to here" and that would save me so much time.

At least in modern languages like C# 9.0, Kotlin, and Swift (and C++ with heavy abuse of templates) a lot of the tedium can be eliminated - but not in the granddaddy of OOP languages: Java. Still to this day, I have absolutely no idea how people can write Java for line-of-business applications (its bread-and-butter!) and remain sane from having to manually manage data-flow, implementing Java Beans, and manually writing by-hand getter-and-setter methods...

Low Code/No Code solutions don’t work because the people involved in implementing solutions are rarely engineers themselves. Most (good) engineers have learned through training and/or experience, well, engineering things, like edge cases, error handling, user experience, efficiency, testing, maintainability, automated testing, and a plethora of other subtle and obvious aspects of system design. I know this quite well because I’ve worked with these so-called low-code and no-code platforms and every one of them I have seen end up having to be taken over by experienced engineers who have been brought in to fix (or in some cases completely rebuild) a poorly-designed system. These platforms typically suffer the “last mile” problem as well, requiring someone to write actual code.

Some people see past tries at something as proof that something will never work. Others see past tries at someone having the right idea, but wrong implementation.

Imagine how many tried flying before we "invented flight", and how many said "oh how they won't learn from the past".

No Code is mostly a code word for outsourcing. You use their app to get it started, realize it won’t meet your requirements, and then pay them to work on it forever. Unless it’s just a marketing Website.

I think this is only partially true. There are aspects of coding which can be abstracted away, either because they're essentially boilerplate or because a simpler description of the solution is sufficient. Ideally if a more complex description is required, one can drill down into the simplified low-code description and add sufficient complexity to solve the problem.

I mean, couldn't many of the existing frameworks be described as low-code wrappers around more complex work flows and concepts?

Everybody promises their no-code solution is going to adopt to the way your enterprise already works, but the truth is you kind of have to go the other way around if you don't want misery.

Some strange comments in here about Low Code, as if they weren’t already successful. There are easily hundreds of apps successfully making use of Low Code to solve problems for people. Some Marketing Automation tools have had them for 10+ Years. Integration tools are also often Low Code.

Nonsense, No/lo-code is the polar opposite of UML, No-code is the ultimate Agile, it’s exciting and fun to build with, because it’s alive, because it executes immediately, resulting in a powerful iterative feedback loop. UML is static and tedious to build, because any gratification is delayed so far into the future. I know because I’ve done both, in fact I’ve invested all of my wealth (many millions) into developing a No-code ERP/CRM platform and it’s incredible - will launch this year.

Comparing UML and No-code is apples to oranges. UML is about generic abstraction without actual implementation. No-code is about domain-specific implementation done using simplified high-level visual constructs instead of general-purpose programming languages. In other words, No-code is programming (just not text-based), while UML is modelling.

Low-code/no-code is simply the CASE tools of the late 80s, or the UML->production system fully automated pipeline of the late 90s/early 2000s, given new life and a shiny coat of paint. The same problems apply and the same people keep buying the same damn snake oil.

Once you can specify your procedures, requirements, and constraints in a way that is specific enough for a computer to read and act meaningfully on, the elements of your specification method become isomorphic to constructs in some programming language. So you've replaced typed-in keywords with clickable symbols or buttons or controls -- but you've in no wise reduced the headwork of programming or made the programming go away.

A spreadsheet is a low code app. Less flexible than a general purpose programming language, but still extremely valuable.

If low code apps simply provide more flexibility and maintainability than a spreadsheet, they’re already winning.

I strongly believe that every tool, every invention, can only innovate/be innovative in one area.

As such what we need is to have the right building blocks and abstraction layers which at the end will mean that something like no or low code will work. It will only work when all the tools that underpin it have been crystallised over the years.

This happens on every layer and is fundamentally why we see so much work repeated, but slightly different. Every language makes different trade offs, therefore all the libraries implement the same functionality but just a bit different this time.

Every once in a while something like UML (too complicated, e.g., due to the use of EJBs), Business Works (too slow), etc comes along which has promise and offers value at the time but just misses the boat to survive until the next generation of revised underlying tools.

I think a certain set of problems requires the thinking of someone who knows how complex systems work and where the pitfalls are.

You can even see this with stepped covid restrictions that rely on infection numbers crossing a certain threshold. Most engineers wlould imidiately see the real world consequences that arise from the lack of hysteresis.

Similar things happen with input sanitization, deciding on formats etc.

Some stuff just takes experience. The actual writing of the code is not the problem, the knowledge of what to do and what to avoid is.

They're trying to commodify writing code. It would bring down the cost of programmers significantly. They won't succeed, I think. Instead AI will probably beat them to it.

> I forgot the law's name but the said law states that "a machine of a certain complexity cannot build a machine more complex than itself"

Isn't this disproved by the evolution of reproductive organisms? That's not necessarily more complex of course, but it's pretty obvious that over a large enough time scale successive machines can become more complex.

Simulink, labview, and gnu radio are all fairly well adopted though they all have their problems. They are all notably not oop, at least not idiomatically. In fact, as most blocks are stateless other than their configuration, you might say the paradigm is closest to functional. UML, with the exception of flow charts was very OOP centric. In a world where I still come across people who use OO as a synonym for "good" I can see why they created it that way, but a tool that shapes your design space can be limiting.

The lack of detail in the models means autogenerators have to have lots of configuration for each item in the diagram. People would brag that 95% of their code was autogen, and I would realize they had spent dozens of hours figuring out ways to use checkboxes and menu selections to generate the code they wanted. Instead of typing it. And all the hideous autogen vode was a nightmare to step through in a debugger. Large labview projects aren't any better really, but they are popular.

> Just because certain information has an essential complexity doesn’t mean that different representations are equivalently complex. There’s an essential complexity to the layout of the London Underground, but it would be considerably worse if you had to represent it with plain text files instead of maps or diagrams.

In general yes. I was only commenting on the assumption that UML can be of a general-purpose programming language, at least in the domain of business automation, or the idea that sufficient modeling can replace coding given the current technology.

There are tools to turn code into diagrams.

I don't know of any that can make it understandable, however. I think that would be a very difficult task, even for quite small, well-designed programs.

Code has a lot of relationships. In 2D it looks like a mess.

What useful information is this going to convey to the business person and how is it going to be better than a conversation with you.

Agreed. Original agile connected developers and customers through valuing sw features. Today's agile is whip-cracking with the value of features obscured from developers who waste customer time doing unjustifiable work. It's more of a social game than one that benefits customers, so it can not last forever.

> Also, developers can have a good approximation to what the customer wants, even without talking to the customer,

Yoep, sure, maybe we even don't need clients. Just developers creating products for themselves. Or just coding for the sake of coding. I've seen that too mamy times. That's why we need product people.

> The more appropriate idea is that you create documentation in the form of diagrams for free.

The problem is the diagrams are hard to create and hard to update and usually don't remain synchronized to the code. If there was a good way to create documents from the code (perhaps with some annotations required), it could just be a Make target and boom, free(ish) documentation.

I feel like my ideal workflow would be a middleground between doing the design up front and just jumping into coding. Before you start coding I feel like you don't have much of an idea of what problems you will run into, resulting in diagrams based on the wrong assumptions. But with code it's easy to loose track of the high level structure of what you are writing. Writing code, then diagramming the high level structure, and then going back to fix the code seems like a good way to go.

> diagramming capabilities over [Kubernetes] YAML

Has been tried: https://github.com/CATechnologiesTest/yipee

Granted, but you can do the same and much more with different methods, and avoid fighting the frustrating, unreliable and time-consuming UML tools altogether.

Yep, they taught us RR in uni in the early 2000s as well, this was in New Zealand.

It could be possible to do something interesting in this space, where UML can be used generate template code, and later on, another tool could extract UML from the code, compare it to the baseline, and flag any discrepancies. From there, you can either sign off on the discrepancies (and replace your hand-made UML with the extracted one) or fix your code. Bit of a kludge, but at least automatic verification is possible unlike documentation

The trick is propagating "backwards" to the model feedback from tests, not changes, preserving the normal loop of receiving requirements, writing code (in this case the "model"), compiling it to something else (including generated code that fools would be tempted to modify) and running the program.

The intersection space in that Venn diagram is generally anotated as "$$$".

The difference I was trying to highlight is that UML (at least in my experience) was still very much focused on "big design up front" and production of design artifacts (vast numbers of diagrams) that agile and TDD approaches explicitly rejected.

I don't remember rapid iteration being a part of any UML-based methodology that I ever used. By the time the diagrams were complete enough to capture implementation details, they were too unwieldy. Did any UML tools support common refactorings, or would you have to manually change potentially dozens of affected diagrams?

Yeah it turned into that before kinda dying. Now in the "real world" those tools are only used for diagrams that explain what's called a "slice" of the architecture, but no one really gives a whole architectural view of a system on UML. Not even for a simple component.

But the glimpse you got of it as an undergrad was UML trying to give it's last kick before dying. The whole quest for a formal definition and a standard for it doesn't make sense if you only want to use it to give an architectural level view.

That assumes that before you have a thing in your hand (a working program with expected input, and output), you can exactly describe how that thing should act, what it should look like, what the input and output should be (and not be) and have that be successful - and structured correctly internally the first time.

In my 25ish years of experience writing code? That has happened for a non trivial task exactly zero times.

If the idea is you could refactor the UML (and hence generated code) to adjust, since none of the tools are able to generate functional code (stubs and simple templates yes, but not much more than that), that means it would need to refactor a bunch of human manipulated and generated code without breaking it. Which I think is well beyond even our current capabilities.

> You'd want to design in some other medium

That's why I really like PlantUML [1].

It generates UML diagrams from a simple text markup language.

Much quicker to iterate on, easy to put into a repo and share or collaborate.

Still not something you would use to design your whole code structure, but great for brainstorming or drafting once you internalized the language a bit.

[1] https://plantuml.com/

> > To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.

> I'd rather spend some time making sure I'm building the right thing, rather than testing that what I built correctly does the wrong thing.

I don't believe the GP was saying to use tests instead of planning. They were saying to use the tests as planning.

They called out property-based testing in which you describe behavior of the system as a set of rules, such as `f(x) % 2 == 0`, and the test harness tests many inputs trying to find the simplest example that fails that criteria.

They also called out defining types (in their chosen language, not a step removed in a UML diagram), which allows you to think about how the data is shaped before you write an implementation that forces a shape.

I agree completely with your first two paragraphs, but UML, in my opinion, failed to support that approach. Its primary failure is that it neither captured nor communicated the rationale behind the requirements, the answers to "why this?", "why this, instead of that?" and "is this right? is it sufficient?" Answering these sorts of question is central to the production of requirements and also to understanding them, but with UML these questions and their answers are treated like scaffolding, taken away from the result before its delivery.

One might argue that UML could support the capture of such information, but what matters is that this rarely, if ever, was done. It is not the sort of information suited to being presented diagrammatically, or at least not by the sort of diagrams that made it into UML.

One might also argue that no other requirements specification method centered on these features has made it into mainstream software development. Some people here, for example, have argued that the code is a statement of requirements, and code also lacks these features. It does not follow, however, that therefore UML should have succeeded.

Ultimately, UML was an added layer offering insufficient benefits to justify its costs. Its benefits were insufficient because it was predicated on the false assumption that requirements can be adequately captured by a sufficient number of simple declarative statements about how things must be, and that the process of specifying requirements is primarily a matter of making such statements.

It certainly isn't the optimal way. Imagine the UML for a metaclass that creates classes, or for composition/trait based object definitions.

The good UML diagrams are sequence and maybe use case.

Why would you ever not want to iterate your design? Doing is the fastest way of learning. The details can drive a design, so that if you don't remove all ambiguity, you will create an architecture that won't actually work. The problem people who just jump in face, is that they do not abandon their bad prototype and begin again, instead clinging to faulty architecture which leaves them in the same boat as someone who made an architecture unaware of the details.

Agreed ... the thing that bothers me about UML is that it has displaced better, smaller-bore tooling in a significant way. The idea of thinking-before-coding work is of course completely necessary.

Yea but, why do we have to speak in Greek in the first place?

Yeah that's why I normally write documentation in English instead of Greek. That way, when people read it, they don't need to learn a new language.

Besides, that's only half of my criticism. Greek is at least a full language where you have the flexibility to phrase things however you want and inject detail wherever you need. UML is a very rigid language which makes it hard to emphasize certain elements over others. A text has a reading order and a logical progression; UML is spaghetti.

If you're gonna write your docs in a different language, at least pick a good one.

> UML is nonsense

Eh, uml is a tool. Pretending to document fully or even to have uml as ground truth is a fool errand, of course, but since our daily job involves taming complexity, any system of knowledge partitioning that one can assume everyone else understand is a godsend

PlantUML is an excellent tool for creating visual representations of system behaviors. Because diagrams are generated from plaintext, they’re easy to maintain and version control. I use it often when designing new features and systems. You don’t need to pay attention to UML semantics to create valuable diagrams.

When I was in uni recently I was learning UML and wondered why all the FOSS tools for UML sucked. I quickly worked out it’s because no foss programmer actually uses or cares about UML

It would be difficult to do really anything with such a pole.

Sure they would. As a widely recognizable set of boxes and arrow shapes, it's useful for the kind of doodling that you might want to show someone else later :).

Challenge accepted.

There are certainly creative ways to sign the contract in order to avoid that requirement, after all we belong to the European nations that tend to be creative when it is time to comply with the law.

For example, I knew some consulting shops that had one poor soul that signed all contracts and hoped for the best.

I'm missing "UML as a satelite map of the wilderness"

it's about 125 lines in elixir:

https://gist.github.com/ityonemo/9f3b8f86a04f2636ab308b1b1a3...

Watched (and still watching) the same thing in the Navy. :(