[jimbokun]

> Instead the developer jammed the huge JSON blobs into a column on an MSSQL table and changed a few lines.

Sounds like quickest way to deliver value to the customer. As described, was far too late in the process to worry about deploying with a clean, extensible architecture.

A reasonable amount of technical debt in order to ship in the timeframe available.

[rswail]

Depends on your definition of "reasonable". You now can't leverage your DBA's skills to optimize queries, because you're using the RDBMS as a key/value store.

You're misusing a tool because you didn't do the correct application design in the first place.

NoSQL has it's place, mostly in the trash. Lazy key/value stores (which is all that NoSQL is) throw away all the benefits of relational logic for a glorified combination of a file system and grep.

That's not "delivering value to a customer", that's delivering crap.

Standard "Agile" response. It was only "far too late in the process" due to a complete lack of process, oversight, product quality ownership and capabilities.

If nothing else, that developer should be "counselled" as should the PO, the Scrum Master and anyone else involved that allowed the situation to occur.

And the ongoing capex and opex for the additional unbudgeted support should be pushed back on the PO as a requirement to fix.

[kazen44]

except that shipping something with semi-broken infrastructure leads to losses down the line.

What if your mongodb database drops its data and now you have production impact? Are those losses calculated while making these decisions during development.