Slashdot Mirror
Invented-Here Syndrome
edA-qa writes: Are you afraid to write code? Does the thought linger in your brain that somewhere out there somebody has already done this? Do you find yourself trapped in an analysis cycle where nothing is getting done? Is your product mutating to accommodate third party components? If yes, then perhaps you are suffering from invented-here syndrome.
Most of use are aware of not-invented-here syndrome, but the opposite problem is perhaps equally troublesome. We can get stuck in the mindset that there must be a product, library, or code sample, that already does what we want. Instead of just writing the code we need a lot of effort is spent testing out modules and trying to accommodate our own code. At some point we need to just say, 'stop!', and write the code ourselves.
Most of use are aware of not-invented-here syndrome, but the opposite problem is perhaps equally troublesome. We can get stuck in the mindset that there must be a product, library, or code sample, that already does what we want. Instead of just writing the code we need a lot of effort is spent testing out modules and trying to accommodate our own code. At some point we need to just say, 'stop!', and write the code ourselves.
I do not see this topic brought up nearly as much, which worries me. I have worked on quite a few projects where the unwillingness to write functionality internally lead to excessive testing of external options and overuse of generic frameworks which not only increased the dependency/complexity of the project but often required just as many lines of code to use as just writing our own damn module would have.
It feels like this is worst in the Java (enterprise) community, but that could be my imagination. Sometimes I think those programmers need their 3rd party instantiation taken away from them....
And crap, looks like I have been moved over to slashdot-beta so I will probably never see if I get responses....
It comes down to the quality of the solution, versus the added headaches of managing dependencies. It's not a religious issue, but one of experience and engineering. It's also a good idea to make sure that if you're inventing something that someone else might eventually provide, you at least loosely couple it, so it can be swapped out later.
With those thoughts in mind, don't get stuck in analysis paralysis. Use judgment and move on.
I'd say part of the cause of "invented-here syndrome" can be "not-good-enough syndrome." I'm often comparing my programming skills to people I see online - people whose skills far outpace my own. So when it comes time to access my programming skills, I'll understate how good I am because I'm simply not as good as those "coding superstars." Of course, when you see the online results of code people have written, you don't see the idiotic mistakes they made, the typos they've had to correct, the hours they spent Googling for an answer to a pesky problem. You just see some elegant, amazing looking code. It can be a daily struggle to balance admiring the programming skills of others without trying to compare myself to them (and thus knocking my own skills).
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
If only we had access to their code base!
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Part of the problem is the CYA issue.
If you're writing the code, you sound like a laborer ("I have to..."). If it breaks, it's your fault and you're on the hook publicly.
If you present a third-party component in a meeting, you sound like a manager ("I propose that we..."). Once three or four other people in the meeting have concurred, if something breaks it's the third party's fault. A ticket or two are initiated, it's someone else's problem and everybody gets to cast blame somewhere beyond the walls of the company.
Rational behavior, regrettably.
STOP . AMERICA . NOW