Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once. It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements. One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious.
CHECKBOXES IN FILEMAKER PRO 6 CODE
If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.įrom a coding perspective taking over these houses of cards are my favorite kind of project. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?Įngineering teams could also move fast if they just threw maintainability to the wind. No design reviews mean you get solutions that are the absolute worst hacks. No ones doing phased deployments with automated rollbacks here in these low code and no code environments.
There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. The authoring of performance regression testing gets skipped. The authoring of automated test suites get skipped.
Because you're not doing "code", the code review step gets skipped. The reality is that these time savings come by cutting corners from the development cycle. Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.
0 kommentar(er)
