Years ago, I was leading the R&D in a start-up. The CEO was full of ideas. Some of them were very good, some really bad, most completely ill-matched to our priorities and limited resources. It quickly became clear to me that my job was being the "that won't work guy", in an attempt to make sure that we managed to finish our project before we ran out of funds.

Almost all the problems we encountered with the project where things that happened as a consequence of me not shooting down random ideas before said CEO managed to get them started. Whenever I came back from PTO, or conference, etc. I regularly discovered that the CEO had split the already direly understaffed team to work on yet another brilliant idea that would make no sense before we even had our product.

A few of the brilliant ideas I managed to shutdown: a reimplementation of git, a home-made bug tracker, a novel abstract interpreter for a programming language that didn't work yet, a transpiler between the old programming language used in-house and the new one, a Google Docs clone, a home-made IDE, a mechanism for storing source code as structured data to a database instead of a flat file...

Things I didn't manage to shutdown: a custom NoSQL database, a home-made project tracker, a homemade front-end framework, a custom HTTP server, a custom standard library, a new type system, ... all of which were distinctly inferior from what was already available, and could possibly have become much better, with years of development which we couldn't afford.

The company managed to release a first version of the product and folded a few months later, out of funding. Of course, shortly before that, I got fired for "blocking" the development of the company.

My conclusion? Yeah, sometimes, "that won't work" is a matter of survival. But if someone needs to throw away their career by being the "that won't work" person, the company risks ending up full of yes people.

Interesting. I read the article as if it was talking about problems that needed solving. You're talking about ideas that (in the interests of the business) need shutting down.

I would probably go with "that's not a good idea" for the latter.

For the former, when brainstorming solutions, never shut down ideas. That's the whole point of brainstorming! If you want to point out downsides, try a variant of "I think you're on to something there, but how would we handle $DIFFICULTY?"

Sure, you should not shut down ideas when brainstorming solutions, but there's a point between brainstorming and implementation where the ideas do need to be reviewed mercilessly. The problem in the parent poster's company wasn't that they brainstormed about a home-made project tracker, it was that they went through with spending development effort on that.

The brainstorming process is designed for generating alternatives, it's not suitable for choosing between alternatives, that needs to be done in a critical "anti-brainstorming" mindset.

It can be both, I read the comment you are answering to as problems that need solving. "A reimplementation of git" or "a home-made bug tracker" could be trying to solve the problem that they didn't have version control nor a bug tracker, but the proposed idea of creating one from scratch instead of using an existing one (in these clear-cut cases) is ill-advised.

In this specific case, both git and a variety of bug trackers were available and very usable. Neither project answered a precise problem we encountered. Both might possibly have answered problems we might possibly have encountered when scaling up, something that never happened.

This is why when you apply to a job, it is as much about you interviewing them, as them interviewing you.

Yes and I completely agree with it but sometimes you need to have some money coming in so you go along with it even if a team implementing a micro services architecture says with a straight face they won’t know what all will have direct access to my micro service data store but expect low double digits. The number I would expect was zero!

What do you mean by custom standard library? At a glance that seems like a good idea to me. A collection of internal and external libraries that we just install no matter what.

Edit: do you mean you're using C and replacing stdlib.h? If so, yeah that sounds like a bad idea

In my experience as a Dev Manager the easiest way to solve this is to put the expectation for coming up with a solution on the interjector or negative person. This is super effective in filtering the passionate contrarians from the the generally negative because it requires the person to do work, and the default to "no" people rarely will take on the responsibility.

Our system has multiple impossible to finish hard to maintain convoluted modules that indeed did not worked.

There's also "I don't know how to do that, and I don't want to learn how."