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.
At some point we need to just say, 'stop!', and write the code ourselves.
I wonder how much of "invented here" syndrome is related with frustration with curation on the popular curated platforms (iOS, Windows Phone, Windows RT, and game consoles). Cryptographic lockdown applied by the operating system publisher blocks end users from writing their own applications or writing a mod for an existing application. Because people are unwilling to go through the organizational overhead of becoming a licensed developer, they stick with the vanilla version of whatever they can get from the platform's official app store.
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.
I've seen the end result of this a lot working in systems integration and engineering. The problem is that, yes, most functionality has been written in some library or available through a public API, web service, whatever. Especially with mobile stuff, Apple/Google/Microsoft give the developer huge amounts of pre-built functionality, and encourage its use.
The overall problems with it are, in my mind,
- Developers and systems people not knowing how that huge chunk of functionality they use actually does what it does
- Introducing dependencies on third party applications which may or may not be around later, have spotty support, etc.
- Making applications more complex to deploy and debug -- "is this my bug or the API's bug? Why is a single row database update taking 45 seconds and 100% of a CPU core?"
The reverse problem on the other hand has the potential to be worse. No one should be coding core functionality that has the potential to fail spectacularly or have major security problems. Examples might be writing your own PKI stack instead of relying on the OS/webserver to do it, designing your own file transfer protocols unless you have a _really_ good reason, and many more. So with NIH syndrome, you have to really trust that your developers did everything right. With IH syndrome, you need to install an application, plus the 45 modules it depends on, plus provide it access to public APIs, etc.
I think the "solution", even though there's no right answer for all situations, is to make sure app developers are actually understanding development. It's too easy to write applications by gluing together pieces. With the framework movement, the pieces are much bigger and hide way more from the developer than, say, a library function.
From my side, in systems, we have way too many admins who are scared of scripting. Windows installations are moving towards PowerShell now, and while very useful, PS hides almost everything from the end user. Scripts that used to be 100 lines of loading/parsing/checking code are reduced to a single call to a chain of cmdlets. Very powerful, but the language itself isn't the most intuitive out there and borrows syntax from many languages. This leads to admins finding something on StackOverflow and copying/using it unmodified and unverified, simply because they don't know what it actually does.
If only we had access to their code base!
--- Most topics have many sides worth arguing, allow me to take one opposite you.
You will always have to write some code of your own. Even if you use a CodeIgniter, AngularJS, and every prewritten function on StackExchange, still, you will have to write some code to configure the frameworks and to pull it all together.
You will always use some of someone else's code, too. Aren't you using Linux or something? You didn't write your own OS, did you? You're using a database, like MySQL or PostgreSQL or something, right? You didn't write your own database system, did you? And are you using a web server like Apache or Nginx?
So the question is not, should I write my own code or use someone else's. The question is where to draw the line.
I'm a web programmer, your typical LAMP developer (well, LAPP --- I use PostgreSQL). Like many PHP programmers, I first concentrated too much on the PHP. PHP is not the best language, as many have said, but I don't think it's quite as bad as people make it out to be. Anyway, I never took up any of the PHP frameworks. They seemed like too much trouble to adapt. (I should point out that I started with an intranet with a dozen or so applications already built.) I would research PHP frameworks from time to time, but always rejected them all, and felt a little self-doubt in doing so: "Do I suffer from Not-Invented-Here Syndrome?"
But PHP, and scripting languages in general, provide the right level of abstraction, I think. It takes care of memory management. It provides a bunch of functions for HTTP. It has its own templating syntax. It's great if you don't overuse it. In other words, in the MVC pattern, PHP does great for the View and, together with Apache, the Controller. But if you write a lot of your Model in PHP, with all this data processing, checking, calculations, etc. --- well, that's what the database is for, I think.
So, instead of eventually adopting a PHP framework, I learned more and more about Apache and PostgreSQL, and I learned that a lot of the things that I was doing in PHP could be done in SQL or in the Apache configuration, with a lot less typing (a lot more reading but a lot less typing). While most people are busy trying figure out how to write the practically all of the MVC in PHP, I realized that Apache was part of the Controller, PostgreSQL was part of the Model, and the browser was part of the View. I use PHP just to help them out, only when needed.
...unless you have to redesign your car to make it fit.
I think the point of the article was that that's sometimes the case.
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