Sometimes you can explain things and not be heard until you demonstrate them. Then they have to accept that you’re not just BSing, that your idea does have at least some merit.
Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
In this case, I’d also watched this all take shape over a couple of months. Being the new person, I assumed it was some necessarily complex beast that was beyond my scrappy experience and calling for Serious Engineering. Once I recognized it for what it was, I knocked out my weekend project shortly afterward because I couldn’t get it out of my head. As much as anything, I had the need to see if it really was as straightforward as I thought it could be. I didn’t sit on my idea for months while they toiled. I watched them toil for months before I understood the core of what they were making.
> Sometimes you can explain things and not be heard until you demonstrate them.
1000%. In my experience this isn't even a "sometimes". It's the opposite. Explaining/arguing in the abstract why a significant directional change is needed has little persuasive power. If you can demo something, you actually have a fighting chance, even if it barely works. It can be a working product, it can be charts, it can be a semi-functional mockup, whatever, but you have to show _something_ that isn't just talking about it. I learned this the hard way after advocating for things and getting shot down too many times.
> Also, never underestimate an enterprise’s ability to convince itself that it’s too big and complex for off the shelf tools. Sometimes that’s the case. Very often it’s not.
Couldn't agree more with this, also. I've seen an astonishing number of homemade job runner systems, homemade message queues, homemade databases, homemade web frameworks, homemade languages, etc.
One can make the argument that this is how technical progress happens, and in some sense, that's true (we wouldn't have a lot of nice things if this never happened), but it's rare. Like, really rare. Most shops would be better served with e.g. Django, Postgres, and HTML, deployed on Heroku (or your Heroku-equivalent of choice) rather than spending hundreds of human-months building "an ad hoc, informally-specified, bug-ridden, slow implementation of half of $COMMON_OFF_THE_SHELF_TECHNOLOGY".
So, I completely agree with you.
Wow, that just gave me a PTSD shudder. I started at one shop and they had a small team continually fighting against their home rolled message queue and task runner. After joining in the fray, asking about a million questions about why this is done like that, etc., I talked them into replacing it with a stock Python Celery setup. The original author of the local version protested, understandably, explaining why it couldn't possibly work.
It worked. It didn't require handholding. It continued working after I left there.
My coworker was a smart guy, but he got it in his head that their specific use case was something that couldn't possibly be served by a COTS project. Turns out, it could, and easily.
This story is more common than any of us would like to admit, myself included.
I can say this with some confidence because as a junior developer, I was often that person, and I didn’t really understand the collective lessons contained within e.g., Rails, Celery, etc.
I was enamored with doing something “cool” and “interesting” and I didn’t realize that this was distinct from and not actually as cool as solving someone else’s problem on time and under budget.