This is just a very bad excuse for doing ridiculously shitty systems that stay shitty way after the startup phase. If you at all bother to understand your problem domain, and are not just a monkey at the typewriter, writing down a good domain model and adding the constraints is not going to decrease development speed, quite to the contrary, it's going to increase it, web developers often spend whole workdays just tracking down in the logs the "story" of some now angry customer that happened to violate some unformalized assumption of the system and got mishandled later in the process, especially if this customer happened to pay already. Not to mention that with a good domain model, the code for the individual functionality flows out naturally, while with a shitty one, you might end up with three times as much code for the same thing.

Also, those mistakes in modelling the domain and in enforcing the constraints are often there to stay and slowly become impossible to fix, once you have 10000 records that do not fall into a few well specified states, it's hard to go through all of them, find some common denominators, and migrate the database. Not to mention that with the mess people can do in the code, and with the messy stack in use today, it's easy to introduce bugs that might be hard for anyone to notice but seriously harm your business.

The amount of fashionable nonsense in software engineering seems to be higher than ever, unfortunately.

> If you at all bother to understand your problem domain

This is a startup. There is no problem domain. There is no spec. There's none for a startup. You may not even have code.

If you're doing a "startup" but have this ironed out, great, everything you said then applies, but it's not a startup, since you found your business model, it's a small company.

And I would love to enforce constraints on the DB but unfortunately, I already had "primary keys" that repeat, unbeknownst to the project customers.

> This is a startup. There is no problem domain.

Is the startup just a game developers do on their free time? Because if it is trying to solve a problem, there is a problem domain, even if it's the wrong problem.

If you understand the problem well enough to write a good domain model then you're basically already there - which is to say, you can only know you're modelling the right domain after you've found product/market fit. But to be able to find that out you need some level of product, which often means having working code before you fully understand what your product really is. At that stage, a schemaless database is very helpful; working out your domain model in detail and typing it out twice would be a waste of time when it's likely to change quickly.

Why do you call it "software engineering"? Do they try to follow SEMAT? SWEBOK? If not then they probably are just software hackers and do not deserve to be called software engineers. A real software engineer is someone who follows rigourous engineering processes, does not reinvent the wheel and who does their work by applying the lessons of those who have gone before. It requires mental discipline to do this, in particular because you have to resist the urge to reinvent the wheel.

Reinventing the wheel is great fun. Without constraints you can appear to be amazingly productive. But it is all a fantasy because without constraints and a rigorous process you are probably piling up technical debt faster than anything else.

And what is wrong with pointing out that "software engineering" is not used to talk about engineering?

Exactly

Relational DBs may even be the wrong choice for some specific problems.

And about this quote from the article: "At some point, you will need to ask your primary database questions. If you chose the wrong database, this is where things get tricky. "

Yes, this is correct. However, I know how to read the manual of whatever db I'm using and maybe code something simple to process the output to the format of my liking.