undefined | Better HN

0 pointsmdbauman2y ago0 comments

Agreed, with the caveat that you also need a policy/culture that the escape hatch should be avoided whenever possible and the low-code work should not be done by developers.

Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career.

But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.

0 comments

3 comments · 1 top-level

closeparen2y ago· 2 in thread

An interesting thing with developers getting involved in those boxes-and-arrows UI things is outages. I made a mistake with one once, and the postmortem quite reasonably asked:

* Where was the design doc?

* Where were the alerts?

* Where was the code review?

* Why didn't you write an integration test?

* What do you mean it just rolled out to production instantly?

When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly.

Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?

Towaway692y ago

For me, none of the learnings is a direct result of using a low-code, arrow-boxes environment. I can deploy instantly to production using any programming environment, if I don't automatically have design documents when using a much-code environment.

Without discipline, any programming environment can lead to failures.

It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.

closeparen2y ago

Are these environments attractive because boxes and arrows are actually better than characters for expressing programs? Or are they attractive because they encourage you to skip steps that turn out to have been important? Sure, you can replicate a normal, responsible development process with a no-code tool, but at that point do you really have a compelling alternative to a more traditional programming environment?

j / k navigate · click thread line to collapse