For me, NoSQL works great when the structure of the data is unclear but you have a fixed identifier that you can key off. SQL when the structure is known and juggling multi-table transactions is not a big PITA.
I'm not sure about the mongoDB nightmare, for me its done everything as the documentation claims it'll do.
> As soon as you have more than one table you switch to NoSQL?
Nope. Just start thinking a bit more if I need to continue using RDMS or switch to NoSQL now. I can when the time is right for the project. It varies for projects. While learning phoenix (elixir) I stuck with postgres because the tutorials were easier to follow. While creating a fancy blog engine I switched to Mongo
That's odd. I don't recall saying more than 1 table is complex. For me, it's just a good time to think more about what kind of database to use, esp for pet projects.
SQL is really good at projecting & selecting simple data. My rule of thumb has been to use it first for any per projects and but as soon I need more than one table, think deeper about the data and switch to NoSQL if I need to represent complex data structures or have document storage needs.
Its still amazing how far you can go with a single table and few tweaks to a postgres instance.
B : Would you rather deliver features or make sure the platform that you're working on stays running ?
For the product/project itself, setup a continuous delivery pipeline. Allow (if possible) one pull request at a time. Let integration/load/benchmark tests prove that its not breaking anything. If the tests are broken, whoever breaks them gets to fix them. They're not in the team anymore? no problem. Whoever needs to push a change, need to make sure the pipeline is working.
Growing team needs direction. Set up tenants / guidelines / vision. Assign product owners that are responsible to customers/stakeholders.
Also, figure out why nobody cares. Is it lack of knowledge / best practices? Is it lack of interest? Is it not-my-job phenomenon ?
I wasn't really going towards defending waterfall[1] but lemme give it a try.
Waterfall might be not bad when you cannot have feedback mechanisms, you cannot roll out changes in phases, where requirements/scopes are fixed, tech stack is well defined and products have matured enough.
[1] : wanted to more say, use the right tool for the right thing in the right way. I don't think its easy but its doable.
Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm guessing same goes for Scrum. I've never followed true scrum so my opinion might be jaded however the devil generally lies in the implementation of the process.
You cannot fit the same tire on a truck and a kid's tricycle, same way you cannot fit the same process for all development cycle. If you team needs clear direction and everything well defined (written in stone), follow waterfall. If your team needs formal process but can do some things on their own (say a team filled with new hires and one lone experienced dev), scrum might not be so bad. Kanbaan is good when everyone knows what they're doing and you really just want to know which stages do you need to focus more on.
You're best bet is probably to try all three and whatever else exists, mix and match until you can successfully deliver your products without a whole lotta overhead and then keep tweaking the process when conditions change (new hires, folks leaving, change in goals/features).
I think this would be something you should ponder and think about on your own. Think of a question that you would like to answer (eventually) and more importantly your dissertation reviewers would like to know about. It doesn't necessarily have to be a tough topic but has to hold interest. Something that fancies me right now is impact of behavioral economics on business policies
I'm not sure about the mongoDB nightmare, for me its done everything as the documentation claims it'll do.