Comment by carbon8 | Hacker News Reader

Comment by carbon8 | Hacker News Reader

I've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals. Anedotally, one of the common responses whenever I reference either company is, "Yeah, but how big is [GitHub|37signals], really?" It's actually somewhat surprising to me how consistently I've encountered this response (so consistent, it feels as if it was distributed like a political talking point). As mentioned in the slides, publicly announced funding definitely serves as a signal, and I haven't heard anyone say that about GitHub since then, though someone said it to me regarding 37signals within the past few months.

What I think it really has to do with is that GitHub seems to make an effort to hire doers, whereas many companies develop processes to deal with non-doers, eg, having staging servers so non-technical staff can check the work of "their" developers. Remote work also doesn't serve the interests of non-doers, since they want to Have Meetings and Make Decisions.

>> staging servers so non-technical staff can check the work of "their" developers

Surely staging servers have some other benefits? Maybe some teams consider running code on the production setup for the first time to be risky to their customers? Perhaps some teams have encountered differences between dev laptops and production servers, which run on different OS/memory/etc. combinations?

Short-lived staging environments (eg, a temporary clone of a production environment) certainly have a place, such as when making architectural changes, but these kinds of changes are generally not happening on a regular basis if you are making incremental changes and doing continuous deployment.

I'm sure that there are companies that have a valid engineering need for perpetual staging environments rather than feature flags, but I've seen absolutely no evidence that staging servers are commonly engineering driven. Certainly in every part of the web startup world I've had contact with or heard about, staging environments have consistently been for product QA in organizations with heavy-handed processes and/or product management by non-technical stakeholders.

Edit for the people responding: This is not about haphazardly pushing to production. You should familiarize yourselves with continuous integration (http://en.wikipedia.org/wiki/Continuous_integration) and the various deployment strategies of major web companies.

You honestly can't think of good engineering reasons not to push new code directly into production?

too busy crushing it to use a staging server

sorry you aren't a technical coder

you probably even file bugs instead of just monkey-patching it in production like a real man

(srcub)

You might want to do fewer, less frequent releases in order to provide training to end users. You might also want to do do fewer, less frequent releases in order to facilitate a marketing push centered around the release.

I'm a dev at a company and I pushed for us to have a staging environment _and_ QA. When I started at my current job, it was common practice to edit code in production, and there was no testing (automated, QA, anything).

In our case, having a staging server (which is really a prod server since it's used for some internal stuff) gives us a chance to check a few things:

1. The installer still installs everything properly. 2. The main website works 3. Web services work

We don't have any hard and fast rules about how long things sit on staging, but having a staging system is useful.

So there you have it, a staging environment driven by engineering.

Staging servers are not only a great idea, they are a life saver (read: job saver/career saver) when you are running large, mission critical apps.

I push things right into production when I'm playing with a new site. I use a staging server when I'm working on something serious.

well I heard New Relic today saying they run their own production monitoring on their staging.dogfood it first...

What really sets GitHub and to a lesser extent 37signals apart is that they are making a product for themselves. That's how they manage to only hire doers. They don't need marketing or usability testing or operations or acquisitions beyond what the doers provide because the feedback loop to the target market is near direct. That's not to say it's easy to do what they've done, but rather it's much less likely those principles could be held as the staple of companies in other markets where engineers and designers will not be as naturally adept at nailing product/market fit by themselves.

> I've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals

Then you can imagine how many people outside of the Bay area do the same thing. I've worked at places where I (stupidly) suggested some of their principles as solutions to systemic problems that came up, assuming that everyone would be on the same page (I mean their ideas just make sense right?) ... no way. I've gotten laughed out of the room a couple of times, wised up and am now resigned to the fact that unless I start my own company or join the founding core of a startup, I'll never get to apply those kinds of ideas unless I work in the Bay

Don't give up so quickly. Sneaking in good ideas into companies is a skill that takes time to learn, and even when mastered takes patiences to exercise.

Reply on news.ycombinator.com