4 ms·

Is NIH syndrome such a big deal with engineers that they need to implement EVERYTHING? I'm leading a team of 3, including myself, and I can't imagine a worse wa

by pm 13y ago

Is NIH syndrome such a big deal with engineers that they need to implement EVERYTHING? I'm leading a team of 3, including myself, and I can't imagine a worse way to spend your time. Why would I spend precious hours re-implementing a non-core problem badly when there's someone already doing it well? When you support a SaaS service, assuming the product is good, you're essentially paying for an entire team to work on a problem you don't like that much but need, but which they love. You're also paying for the future of that product. Unless the software is really bad, or you need something so specialised that a current solution is out of the question, how does an engineer not understand this? You only have limited time in the world. Work on something you find meaningful.

marquis 13y ago
If you hark back to the days before, say even 2010, there just weren't many SaaS's that worked or were affordable. We ran our own ticking system, chat, accounting, hosting, email servers, error reporting, server load checks.. it was all handmade cobbled together from open source and when we were running as fast as we could to get products together it was quite a mess yes, but there was no Github, Google Apps, Hipchat, OpenHosting, whathaveyou, and looking at our own list I see we have now a huge amount of stuff we used to build ourselves thanks mostly I suppose to what we find on HN as it comes up, and the article is spot on - definitely costs less than a full time employee to run all this. However my point? This is all terrible for security, we're reliant on someone else's data integrity, and I would assume it's safe to say that if we had the time to have someone do all this in-house and maintain good documentation we wouldn't hesitate, given the security and data integrity tradeoffs.
- pm 13y ago
  You make some good points, and HN has been such a boon for finding new services to integrate. Of course, if we could all do it in-house reasonably we'd all be doing that no doubt, but it's just not feasible, even for large corporations. Who can justify the cost? Security is always a concern, and I do hope most services have taken heed of online security breaches in recent history. However, I don't find it an argument against using SaaS because most of the time, the security from doing software in-house is dispelled by poor security in meatspace, i.e., social engineering (which is WAY easier to do than people suspect).
wtracy 13y ago
At least two out of the three enterprise(ish) software companies I've worked at had their own in-house bug trackers, their own in-house build systems, and their own in-house version control systems. (To be fair, the versioning systems were custom front-ends over Rational Clearcase at one and Perforce at the other, but still...) The third had it's own in-house monitoring and logging infrastructure. (One team maintained its own monitoring daemon entirely because they preferred to do that than learn how to use Nagios!) As you might guess, I was very frustrated by how much time I spent re-learning how to do the most trivial tasks when I switched jobs. So, yeah, NIH is a real thing.
amalag 13y ago
Depends case-to-case. It is very strong with some people. They are very intelligent, but I think they rely on their own programming too much. I worked with someone and we needed a file storage mechanism for a startup that needed to launch yesterday. So I was pushing to put it on AWS, simple enough. The CTO thought we would be locking ourselves in (for a startup that had yet to launch, yet alone make any money) and wanted to make some extra abstraction layer and then make his own file managing API so that he could plug in his own in house datacenter storage later. Such a colossal waste of time and the startup never launched. I am sure there were other things, but I could never see eye to eye with that person. Should have used something simple like filepicker.io to launch and then looked at it later.

by pm 13y ago

marquis 13y ago

If you hark back to the days before, say even 2010, there just weren't many SaaS's that worked or were affordable. We ran our own ticking system, chat, accounting, hosting, email servers, error reporting, server load checks.. it was all handmade cobbled together from open source and when we were running as fast as we could to get products together it was quite a mess yes, but there was no Github, Google Apps, Hipchat, OpenHosting, whathaveyou, and looking at our own list I see we have now a huge amount of stuff we used to build ourselves thanks mostly I suppose to what we find on HN as it comes up, and the article is spot on - definitely costs less than a full time employee to run all this. However my point? This is all terrible for security, we're reliant on someone else's data integrity, and I would assume it's safe to say that if we had the time to have someone do all this in-house and maintain good documentation we wouldn't hesitate, given the security and data integrity tradeoffs.

pm 13y ago
You make some good points, and HN has been such a boon for finding new services to integrate. Of course, if we could all do it in-house reasonably we'd all be doing that no doubt, but it's just not feasible, even for large corporations. Who can justify the cost? Security is always a concern, and I do hope most services have taken heed of online security breaches in recent history. However, I don't find it an argument against using SaaS because most of the time, the security from doing software in-house is dispelled by poor security in meatspace, i.e., social engineering (which is WAY easier to do than people suspect).

wtracy 13y ago

At least two out of the three enterprise(ish) software companies I've worked at had their own in-house bug trackers, their own in-house build systems, and their own in-house version control systems. (To be fair, the versioning systems were custom front-ends over Rational Clearcase at one and Perforce at the other, but still...) The third had it's own in-house monitoring and logging infrastructure. (One team maintained its own monitoring daemon entirely because they preferred to do that than learn how to use Nagios!) As you might guess, I was very frustrated by how much time I spent re-learning how to do the most trivial tasks when I switched jobs. So, yeah, NIH is a real thing.

amalag 13y ago

Depends case-to-case. It is very strong with some people. They are very intelligent, but I think they rely on their own programming too much. I worked with someone and we needed a file storage mechanism for a startup that needed to launch yesterday. So I was pushing to put it on AWS, simple enough. The CTO thought we would be locking ourselves in (for a startup that had yet to launch, yet alone make any money) and wanted to make some extra abstraction layer and then make his own file managing API so that he could plug in his own in house datacenter storage later. Such a colossal waste of time and the startup never launched. I am sure there were other things, but I could never see eye to eye with that person. Should have used something simple like filepicker.io to launch and then looked at it later.