Hacker News Reader

Comment by generalk | Hacker News Reader

  > So, you could have delayed the app by the same amount 
  > but now have a mongo environment for production as well?

No, we couldn't have. Not just because we didn't want MongoDB, which at the time was notorious for data loss, but because our ops team didn't have the capacity at that point in their schedule or team size to handle it. Maybe had we discussed at the beginning of the project plans could have been made or altered, but we didn't and so they couldn't.

  > Seems a bit of a waste to rewrite the app instead.

The responsible dev took the time necessary to rewrite the data layer to better reflect the needs of the application.

Is what I wish had happened. Instead the developer jammed the huge JSON blobs into a column on an MSSQL table and changed a few lines. lolsob.

View on HN

> 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.

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.

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.

> because our ops team didn't have the capacity at that point in their schedule or team size to handle it

Lol, I get your point, but that was also true for the dev organisation. Hence what you ended up with.

I doubt the needs of the application included a rewrite in MSSQL.

Reply on news.ycombinator.com