5 ms·

In principle, at least for business applications, the middle ground is something like low code - data access, UI, user management, authentication, logging, audi

In principle, at least for business applications, the middle ground is something like low code - data access, UI, user management, authentication, logging, auditing, ... all taken care of already, you make the data model and business logic. In practice this works up to a point, when you have requirements that do not fit the model or capabilities that the creators of the platform had in mind, when you have to start fighting the platform, then you are right back in wtf code land. When you decided which platform to use, you of course evaluated this and made a good choice, building the first version worked nicely. Now you have a running system and want to extend it, now you are getting the more unusual requirements that were not important for version one and therefore not taken into account when making the platform choice, now your nightmare starts.

j-a-a-p 3y ago
Yes, reminds me of about 25/30 years ago when low code was at its high. Back then there were strict guidelines where to put business logic (client, server or both), how to name them. Everything had to originate from the model (model driven development). Since then the developers took over and killed waterfall and 4GL in the process.
- CPLX 3y ago
  Genuine question, what were the low code frameworks that were popular in the late 90’s that you’re referencing here?
  - j-a-a-p 3y ago
    Forgot most of that, I consider this 'enterprise period' in my life as pretty boring. There was one product really popular then, but forgot the name. Sorry. A product I personally know is Oracle Designer. This could generate fairly complicate applications (like master-detail-detail layouts) based on the ERD. Another product I also forgot it's name, was considered very good, but used only within the IBM ecosystem. Fun fact, I was the product owner for a project where the IBM team vastly outperformed the web team (think half the size, twice the speed).
    - cromulent 3y ago
      RPG?
ZaoLahma 3y ago
... and this is when the development company (architect, technical director, ...) decides to extend the "data" models to the point where you've invented a programming language in XML. A programming language too advanced to use even for the programmers that invented it, let alone the "no code" people that it was intended for. A programming language with all of the complexities and none of the tooling that you would expect from a programming language, where failures are caught in runtime since you have no compile time checks of the XML that you throw at it. Next step is, of course, to extend the XML validation to make sure it conforms to your application's expectations. And suddenly you have invented a compiler as well.
- _glass 3y ago
  But isn't that something of the past? I am mostly working with systems that handle the bulk of the problem, providing process, data model, etc. And extensions are done via a specific programming language, ABAP for SAP, APAX for Salesforce, but in the end, it all ends up to be like any other software development projects, with compile time checks, etc.
  - ZaoLahma 3y ago
    > But isn't that something of the past? I most certainly hope so. But I've been involved in extending a system as I described as recently as a few years back. Everything was supposed to be configurable (by no-code customers) and XML was the language of choice, so the XML was... complicated.
atoav 3y ago
That is why talking is important. Get all (or a good sample of all) the people who are going to use your software and discuss a draft/UI mockup. Get them in the mood where they go wild and creative and spit out all kind of ideas. Rinse and repeat till you get a coherent picture and a list of likely additional requirements. Add potential future requirements that you could think of and keep them in the back of your mind. When everything is done you can offer those. This might not catch all the surprise requirements, but it might catch the worst ones. A sure way to get surprised is to do the opposite: - don't talk to the people who use your software, but some middle-men - just take the customers first idea as gospel and assume they disected the problem space themselves - keep everything constrained and never let anybody get wild or crazy with ideas - don't anticipate potential future requirements and don't let them influence your decisions ever Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.
- thom 3y ago
  Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.
  - danbruc 3y ago
    This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.
rednafi 3y ago
Surprisingly few numbers of businesses are fortunate enough to land on the wtf code land.

j-a-a-p 3y ago

Yes, reminds me of about 25/30 years ago when low code was at its high. Back then there were strict guidelines where to put business logic (client, server or both), how to name them. Everything had to originate from the model (model driven development). Since then the developers took over and killed waterfall and 4GL in the process.

CPLX 3y ago
Genuine question, what were the low code frameworks that were popular in the late 90’s that you’re referencing here?
- j-a-a-p 3y ago
  Forgot most of that, I consider this 'enterprise period' in my life as pretty boring. There was one product really popular then, but forgot the name. Sorry. A product I personally know is Oracle Designer. This could generate fairly complicate applications (like master-detail-detail layouts) based on the ERD. Another product I also forgot it's name, was considered very good, but used only within the IBM ecosystem. Fun fact, I was the product owner for a project where the IBM team vastly outperformed the web team (think half the size, twice the speed).
  - cromulent 3y ago
    RPG?

ZaoLahma 3y ago

... and this is when the development company (architect, technical director, ...) decides to extend the "data" models to the point where you've invented a programming language in XML. A programming language too advanced to use even for the programmers that invented it, let alone the "no code" people that it was intended for. A programming language with all of the complexities and none of the tooling that you would expect from a programming language, where failures are caught in runtime since you have no compile time checks of the XML that you throw at it. Next step is, of course, to extend the XML validation to make sure it conforms to your application's expectations. And suddenly you have invented a compiler as well.

_glass 3y ago
But isn't that something of the past? I am mostly working with systems that handle the bulk of the problem, providing process, data model, etc. And extensions are done via a specific programming language, ABAP for SAP, APAX for Salesforce, but in the end, it all ends up to be like any other software development projects, with compile time checks, etc.
- ZaoLahma 3y ago
  > But isn't that something of the past? I most certainly hope so. But I've been involved in extending a system as I described as recently as a few years back. Everything was supposed to be configurable (by no-code customers) and XML was the language of choice, so the XML was... complicated.

atoav 3y ago

That is why talking is important. Get all (or a good sample of all) the people who are going to use your software and discuss a draft/UI mockup. Get them in the mood where they go wild and creative and spit out all kind of ideas. Rinse and repeat till you get a coherent picture and a list of likely additional requirements. Add potential future requirements that you could think of and keep them in the back of your mind. When everything is done you can offer those. This might not catch all the surprise requirements, but it might catch the worst ones. A sure way to get surprised is to do the opposite: - don't talk to the people who use your software, but some middle-men - just take the customers first idea as gospel and assume they disected the problem space themselves - keep everything constrained and never let anybody get wild or crazy with ideas - don't anticipate potential future requirements and don't let them influence your decisions ever Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.

thom 3y ago
Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.
- danbruc 3y ago
  This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.

rednafi 3y ago

Surprisingly few numbers of businesses are fortunate enough to land on the wtf code land.