6 ms·

Paying Money To Save It And Doing More With Less

46 points by bbrunner 13y ago

nfm 13y ago
I have mixed feelings about this, but that might just relate to a certain subset of SaaS products we've used - namely products that require heavy integration with your data. I'd sooner spend engineering time writing our own report generators than writing code to push data to another service, in the format they expect, pre-empting which data we might want to have in that service down the track, understanding exactly how the different reports are calculated, and then inevitably having to write a few custom ones of our own as well. Of course, the exception to this are services have a huge set of useful features and take basically no time to fully integrate with, like Google Analytics.
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.
PaulHoule 13y ago
The "we don't buy software here" syndrome is going away. GitHub is a bit part of it. At a lot of shops you have time to drive to the next town and back to update the Wiki or close out a trouble ticket. Uncompromising speed is a feature that turns your developers into winners.
greenyoda 13y ago
The risk of outsourcing to an SaaS is that the vendor can disappear - it may be a small startup that goes bankrupt, gets acqui-hired, pivots to a different product, etc. Or maybe they can't provide the bandwidth you need to grow or the 99.9% uptime your customers are demanding. At that point you have to scramble to find a replacement SaaS or implement the service in-house. I have nothing against paying for software that someone else wrote, but I'd feel much more comfortable buying the software and running it on my own servers (with a contract that says that if the vendor goes out of business, I retain the right to use the software).
nahname 13y ago
Jenkins easily runs on a $20/month digital ocean box and should take less than 2 hours to setup. I scripted jenkins to shutdown and wake up the workers on heroku during off hours. It took me less than five minutes to script up the job and saves us $35 a month per environment. Effectively, jenkins costs nothing per month (actually saves us money). Most testing services are horribly over priced and you don't get that level of control. Maybe you want to reconsider that one? http://travis-ci.com/plans http://travis-ci.com/plans https://circleci.com/pricing https://circleci.com/pricing https://www.digitalocean.com/community/articles/how-to-install-and-use-jenkins-on-ubuntu-12-04 https://www.digitalocean.com/community/articles/how-to-insta...
- arohner 13y ago
  Thanks for the link! (founder of CircleCI here) Before Circle, I led multiple engineering teams, building multiple products from "nothing" to "shipping, and making lots of money". I set up buildbot, hudson, bamboo, jenkins, and some other things I don't even remember the name of. I was always the build guy, I was always the one that said "yes, we will be testing, yes, the build will be green." Those were controversial statements back then. I've been there, done that, and I didn't want to set up Bamboo again. I didn't want to debug why the tests failed. That's why I built Circle. Our customers, most of whom switched from Jenkins, will tell you we are a steal. Maybe your project is still simple. Maybe your platform is fairly stable. But for most professional developers, keeping CI running and green is a challenge. Even at Circle, I spend more time than I'd like debugging the test suite. But we're fixing that. Every day is spent making devs lives easier. Jenkins costs you nothing per month, but your developers cost money, and Circle's hardware is faster than digital ocean, and the cost of keeping the build green on Circle is lower than the cost of keeping it green on Jenkins anywhere else. If you're running a startup, or a tech company, odds are very good that salary is the number one cost center. Optimizing your Digital Ocean bill is penny wise, pound foolish.
  - nahname 13y ago
    >Maybe your project is still simple. It's moving past the simple app point that gets problematic on someone else's solution. I have dependencies on postgres, redis and elasticsearch within the application. I need a browser too run the feature tests. I need phantomjs to run the javascript suite. Is there any saas offer that covers these? >...keeping the build green on Circle is lower than the cost of keeping it green on Jenkins anywhere else Keeping the build green involves my team figuring out what we broke. Faster build times help, is that what you mean here? Don't even get me started on the stuff we are doing with deployment automation... Edit: I think it was too hostile initially, appologies
bluedino 13y ago
Article is extremely hard to read on my phone.
- bbrunner 13y ago
  Thanks for the heads up. Redid some styling recently. Haven't checked mobile yet. Yea, it's real bad haha.
melindajb 13y ago
Love this idea. Of course it assumes one finds the right software quickly without too much time and hassle.
Xorlev 13y ago
Agreed. I used to think it was best to "do it yourself so you know it" but was quickly abused of that notion. Do important things yourself (if you can do it better -- the stuff the makes or breaks your business). SaaS is a godsend. TRWTF is that the author knows someone who reimplemented NodeJS in house.
drsim 13y ago
An engineer reinventing the wheel, other than an intellectual exercise, can be a symptom of them being bored with their work or not feeling ownership of the company mission. Building something from scratch exactly how you want to is stimulating, gets you respect from peers inside and out and is something you completely own. When an engineer develops NIH it can be a cry for help. Their leaders need to inspire them to refocus on their customers.

46 points by bbrunner 13y ago

nfm 13y ago

I have mixed feelings about this, but that might just relate to a certain subset of SaaS products we've used - namely products that require heavy integration with your data. I'd sooner spend engineering time writing our own report generators than writing code to push data to another service, in the format they expect, pre-empting which data we might want to have in that service down the track, understanding exactly how the different reports are calculated, and then inevitably having to write a few custom ones of our own as well. Of course, the exception to this are services have a huge set of useful features and take basically no time to fully integrate with, like Google Analytics.

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.

PaulHoule 13y ago

The "we don't buy software here" syndrome is going away. GitHub is a bit part of it. At a lot of shops you have time to drive to the next town and back to update the Wiki or close out a trouble ticket. Uncompromising speed is a feature that turns your developers into winners.

greenyoda 13y ago

The risk of outsourcing to an SaaS is that the vendor can disappear - it may be a small startup that goes bankrupt, gets acqui-hired, pivots to a different product, etc. Or maybe they can't provide the bandwidth you need to grow or the 99.9% uptime your customers are demanding. At that point you have to scramble to find a replacement SaaS or implement the service in-house. I have nothing against paying for software that someone else wrote, but I'd feel much more comfortable buying the software and running it on my own servers (with a contract that says that if the vendor goes out of business, I retain the right to use the software).

nahname 13y ago

Jenkins easily runs on a $20/month digital ocean box and should take less than 2 hours to setup. I scripted jenkins to shutdown and wake up the workers on heroku during off hours. It took me less than five minutes to script up the job and saves us $35 a month per environment. Effectively, jenkins costs nothing per month (actually saves us money). Most testing services are horribly over priced and you don't get that level of control. Maybe you want to reconsider that one? http://travis-ci.com/plans http://travis-ci.com/plans https://circleci.com/pricing https://circleci.com/pricing https://www.digitalocean.com/community/articles/how-to-install-and-use-jenkins-on-ubuntu-12-04 https://www.digitalocean.com/community/articles/how-to-insta...

arohner 13y ago
Thanks for the link! (founder of CircleCI here) Before Circle, I led multiple engineering teams, building multiple products from "nothing" to "shipping, and making lots of money". I set up buildbot, hudson, bamboo, jenkins, and some other things I don't even remember the name of. I was always the build guy, I was always the one that said "yes, we will be testing, yes, the build will be green." Those were controversial statements back then. I've been there, done that, and I didn't want to set up Bamboo again. I didn't want to debug why the tests failed. That's why I built Circle. Our customers, most of whom switched from Jenkins, will tell you we are a steal. Maybe your project is still simple. Maybe your platform is fairly stable. But for most professional developers, keeping CI running and green is a challenge. Even at Circle, I spend more time than I'd like debugging the test suite. But we're fixing that. Every day is spent making devs lives easier. Jenkins costs you nothing per month, but your developers cost money, and Circle's hardware is faster than digital ocean, and the cost of keeping the build green on Circle is lower than the cost of keeping it green on Jenkins anywhere else. If you're running a startup, or a tech company, odds are very good that salary is the number one cost center. Optimizing your Digital Ocean bill is penny wise, pound foolish.
- nahname 13y ago
  >Maybe your project is still simple. It's moving past the simple app point that gets problematic on someone else's solution. I have dependencies on postgres, redis and elasticsearch within the application. I need a browser too run the feature tests. I need phantomjs to run the javascript suite. Is there any saas offer that covers these? >...keeping the build green on Circle is lower than the cost of keeping it green on Jenkins anywhere else Keeping the build green involves my team figuring out what we broke. Faster build times help, is that what you mean here? Don't even get me started on the stuff we are doing with deployment automation... Edit: I think it was too hostile initially, appologies

bluedino 13y ago

Article is extremely hard to read on my phone.

bbrunner 13y ago
Thanks for the heads up. Redid some styling recently. Haven't checked mobile yet. Yea, it's real bad haha.

melindajb 13y ago

Love this idea. Of course it assumes one finds the right software quickly without too much time and hassle.

Xorlev 13y ago

Agreed. I used to think it was best to "do it yourself so you know it" but was quickly abused of that notion. Do important things yourself (if you can do it better -- the stuff the makes or breaks your business). SaaS is a godsend. TRWTF is that the author knows someone who reimplemented NodeJS in house.

drsim 13y ago

An engineer reinventing the wheel, other than an intellectual exercise, can be a symptom of them being bored with their work or not feeling ownership of the company mission. Building something from scratch exactly how you want to is stimulating, gets you respect from peers inside and out and is something you completely own. When an engineer develops NIH it can be a cry for help. Their leaders need to inspire them to refocus on their customers.