|
My version of low code is writing HTML pages with a big script element full of vanilla JavaScript, and putting them in this one git repo we have which gets deployed to a web server. Obviously it's not actually low code, it's 100% code, but it creates a space without a lot of the complexity and ceremony of 'real' software development. I don't write tests, I don't future-proof, I don't set up deployment or monitoring machinery, I don't worry about anything except solving a small, well-defined problem quickly. It's definitely not a good approach to everything. But it's quite common for one of my users to say something like "I need a dashboard showing how the current reactor temperatures compare to the averages for yesterday, and also the available cooling water for each one", where that's all data we have existing websocket feeds for, and I can get that to them very quickly without it becoming formal feature development. Lack of testing and monitoring means the products often break. But when they do it's typically benign - the page doesn't load, or shows no data, and if a user needs to use it, they'll complain, and I can fix it. If a page ever got too complicated, or too critical, I might want to port it onto real software. But that hasn't happened yet. |