3 ms·
Aww shucks. Thanks for the shout out. I realize reading this again that I owe a more significant writeup -- I started one not long after this and wasn't happy
by bane 10y ago
Aww shucks. Thanks for the shout out.
I realize reading this again that I owe a more significant writeup -- I started one not long after this and wasn't happy with how it was shaping up. Maybe I'll have another go at it.
Since writing that comment two years ago I've added a couple more examples consistent with the ones in the original post.
One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. When they're working with the platform, and hitting the inevitable and unplanned for performance issues (because, you know, just shove the node to the hadoop cluster and it'll magically take care of that), the solutions never tackle the algorithmic bottlenecks but instead seem to focus on messing with the platform or changing platforms, or changing run-time languages or throwing more hardware at it.
If you are having trouble taking the nuts off your wheel to change a tire, using a bigger hammer or a blow torth isn't going to help. Take the time to find the wrench, of the right size, and then things will work much better.
- qwertyuiop924 10y agoI mean, you get shoutouts every day. Thanks for responding to this one. >One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. Ahhh yes. The "when X is your hammer" problem. In this context, I think the appropriate incarnation is, "When Hadoop is your hammer, everything looks like 1000 nails to be hit very quickly, using brute force."