People often use Lambda School as a poster child for using nocode tools; we used (and use) a lot, which lets everyone (including nontechnical ppl) ship very quickly. Great!
BUT
If nocode changes affect your data model, you’re creating outrageous amounts of technical debt.
BUT
If nocode changes affect your data model, you’re creating outrageous amounts of technical debt.
For example, if someone can notice data they’re missing and are able to quickly add columns to a base, that’s awesome. But without understanding the technical implications of doing so everything can break.
There’s not really a safeguard against that.
There’s not really a safeguard against that.
“But you can just move over what you’re doing to a normal database whenever you want.” Well, kind of. As long as
1. You can freeze all of the data while you migrate (unlikely)
And
2. The data model still makes sense (unlikely)
1. You can freeze all of the data while you migrate (unlikely)
And
2. The data model still makes sense (unlikely)
In retrospect I wouldn’t start doing anything in them without a well-architected data model that only select people can change, and ideally a team turning the nocode into traditional code as quickly as possible.
With great power comes great potential for technical debt.
With great power comes great potential for technical debt.
Oh, and if you are one of the many people over the years who have emailed me saying, “Will programmers all lose their jobs as nocode becomes more prevalent?”
Hahahahahaha no.
Hahahahahaha no.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
