I don't know enough about the others to make too much of a sweeping statement on them, but the heart of Mythical Man-Month is absolutely true and valid. It just has a bad title, so people assume it means something it doesn't.
The heart of the story is this: Adding developers to a delayed project will only delay it further. It's not about parallel vs serial. It's about project management and how to handle delayed projects. I have yet to meet a PM in my career who really understands this, and almost all of them have referenced the saying, "Nine women can't have a baby in a month."
To claim that it's "crap," "critically flawed," and "wrong" strikes me as naive, overly general, and dismissive because you can throw it into a "Gladwellian" bucket and be done with it. Fred Brooks learned his lessons from years of project management. This wasn't a guy who conjured up an idea for a book or a TED talk and just slapped some crap together.
Whoa. Timeout. This isn't political correctness--it's basic human decency. Political correctness is replacing the use of a term for a euphemism. Even putting this in euphemistic terms should be completely unacceptable. If I told somebody at work that they were so stupid, I wasn't sure how they survived childhood, I'd be asked to leave, post haste.
I think that the OSS community (and IT community in a broader sense) has this idea that "they're just words," and so therefore, they should just be able to say what they want without consequence. But, words matter. A whole lot. Empires are built upon words. People rally around words. Words convey ideas, thoughts, feelings, and everything that goes with them. Why is rampant bullying accepted in this culture? Why is it the norm?
I'm not saying that things have to be all sunshine and rainbows. Yeah, sure, it's stupid to read a byte at a time, but you don't have to be an asshole about it. You can say, "Hey, that won't work," and be done with it. People should be treated with a modicum of decency. Remember the human, and all of that.
Contrary to this, I find myself envious of a person who can dress down another in a flagrant and creative way.
If I got dissed in such a hyperbolic way from a boss that was paying me, I would leave.
In a situation where I've toiled in a position of importance in a project I work on in my free time, and I screwed up, I think I'd be hurt if I was dismissed lightly and without creative ire. I mean, I want to know that if I screwed up, I screwed up enough for someone to admonish me creatively, since there isn't any method of management. Your tool is primarily shame, you can't suspend someone without pay from a mailing list.
Well, presumably a job well done is the primary motivation, or perhaps the recognition of your peers. It is only when you have previously achieved importance and are now in a position to have face to lose; here is where shame can come into play.
Constructive criticism is helpful and should always be the first stop on the train. But if you should already know better, or that ground has already been well-trodden, then it just sounds patronizing. This is where being told to shape the fuck up is the kind of message I would expect to receive.
What would be even worse is being ignored or shunned.
I'd go quite a bit further. Most users have no idea what they actually want. I think the key to building a dashboard is to ask three questions:
1. How do you measure success? -- or -- How will you know that life is good? How do you know that the sky is falling?
2. If you see this number (something specified in #1) go above or below a certain value, what are you going to do? Anything?
3. When and where do you need to have the info from #'s 1 and 2 to actually take action? i.e.-Do you need to be inside the warehouse? On your phone? At your desk? Daily? Monthly? By the minute? Push?!
1 tells you what to put on the dashboard, 2 tells you how to prioritize the information (something that's important but not actionable will be something that can be found, but isn't prominent or on display above-the-fold), and 3 tells you the form factor/latency that's needed.
I've built a lot of dashboards over the years. Some have completely changed businesses. Some have languished in obscurity. Most are used fairly regularly (at least monthly), but don't actually add much value beyond time savings of having the numbers automated. The ones that really changed businesses and provided some benefit beyond just time savings have had clear answers to those three questions.
I would add a 4th also based on extensive experience, can the users do anything at all about the situation? Being able to order someone to generate numbers doesn't mean the recipients are permitted or capable of doing anything at all. It shows they "care" but a random number generator is more effective WRT dev time than trying to generate meaningful numbers.
I've seen dashboards get tied up in internal politics. The list of recipients of "quality" dashboard is a line in the sand vs the "quantity" dashboard political group. The recipient list and who controls it is far more important than the data contained in the report. Whats important is who reports to who, and why.
A fifth question is does anyone in the chain of command even remotely understand basic statistics like error bars and standard deviations? If the only purpose of the report is to loudly trumpet when pet division B beats divisions A and C thru G, then a very high std deviation / error rate makes stack ranking give the predetermined "correct" result more often. I've seen this personally in "metrics as a teambuilding exercise" where whats actually produced is a weekly report that every division will get to stack ranking win at least once a quarter to meet the Morale Improvement goal on some exec's goal list. Again a PRNG gives better data than real data, if the goal is to give everyone a participation trophy.
There is a dedicated thread for monitoring the socket so clients don't block trying to write. In case of transient load spike or slowness in Kafka, the bulk of the queueing should occur inside the daemon, where you can see queue lengths via web interface. God luck with your project :-)
I've been in the BI and data warehousing industry nearly my entire career, so hopefully I can help a bit.
1. Get an MBA if you want to transition more to management. This will relinquish really any technical responsibilities. MBAs matter a lot trying to get manager roles at large companies. They also are brilliant for networking--you can have a safe haven to meet potential cofounders who are very good at the business side of things while you work on the technical aspects. That said, just like I wouldn't encourage a woman to go to college to find a husband, I don't encourage you to go get an MBA just to find a co-founder. It's something you should be open to, but it may not happen.
2. The space is definitely moving quickly, but there's still a lot of traditional data warehousing stuff out there. Unfortunately, it's increasingly commoditized. If you're not getting a job because you don't know the latest technologies, then you should probably learn them. This would most likely be a bit more valuable use of your time than an MBA if you really want to remain technical. It may or may not be Hadoop (you may want to latch onto Cloudera or Hortonworks), but whatever your local market is bearing--I actually see quite a bit of variation throughout the country in terms of tools being used. If, however, you're not getting jobs because your price is too high, you may want to take the time to learn the things that will increase your value while biding time on the lower paying projects.
3. I don't know immigration law well enough to have any sort of comment about a startup in the US vs India.
Clearly, no offer (in any realm) will ever be perpetually valid. Giving a reasonable amount of time to evaluate options and make a better decision is considerably less explosive than one that puts an artificially tight deadline on the decision.
Within Excel, ranges ignore blank cells in computation, but a reference to a blank cell returns 0. The idea being that if you specify a cell in a computation, you're expecting something to be there, whereas when you have a range, you may have sparse data throughout that range, and therefore, the result shouldn't break.
OP was probably referring to the fact that things sold in the UK are generally more expensive than the US. Something sold in the US for $100 might be £100 in the UK, even though the conversion rate would have you think it should be £60.