We like to use hosted services rather than host them on-prem where possible (AWS, Artifactory, Slack, GitHub).
For the size of our company we have relatively few engineers. Not hosting things ourselves increases our productivity and we can concentrate on our own products :-)
Haha we probably spend a lot on toilet paper as we have ~5k employees (FTSE 100 company) but that isn't the point I was trying to make :-) it doesn't matter how big or rich you are - if costs for a thing increase by x3.5 it's probably going to have an impact. I'm no enterprise-lover and we spend tons of money on crap with annoys me but I'm not in a position to change that.
We are not a "technology company" (and unfortunately I'm not the CTO!) so we will have to report upwards that costs will be increasing x3.5. Their reaction will probably be to ask us to investigate alternatives.
It looks like smaller companies/startups will benefit much more from this change which is fair enough to charge the big boys more really.
I'm not asking anyone to get their violins out but it makes me a little sad that we may have to move away from GitHub. On the flip side, GitLab has been looking great lately!
This has almost quadrupled our monthly cost ($850 vs $2914). We have ~300 users which will have to be reduced massively to save costs - perhaps with non-engineers sharing accounts or having no access at all. I'm not sure if charging per user is really in the spirit of open collaboration that GitHub champions.
I slo wonder if charging per user rather than per repo will also discourage the creation of open-source repos from orgs? There's no longer a (reduced) cost benefit after all, even if that was a minor influence compared with the other benefits of open-sourcing your code.
If DHH's main concern was practicality he wouldn't advocate UI & DB tests which are flaky, unreliable and expensive to maintain for any non-trivial application.
Code and system architecture absolutely should be bent to the needs of testing. Pretty and "clever" code is useless unless it does what it's supposed to do.
UI & DB tests absolutely have their place - I'm not disputing that at all, and I completely and whole-heartedly advocate their use - but they need to be used in conjunction with very fast, very reliable (and thus very useful) unit/integration tests that have been TDD'd.
I think you're perhaps missing the point in one or two places.
Cucumber helps techies (devs, testers, etc.) and non-techies (product owners, scrum masters etc.) work collaboratively. I don't think the authors of Cucumber ever said that it enables non-technical people to 'read and understand the underlying code'.
Ultimately though, I agree with your conclusion but for slightly different reasons. I use both RSpec and Cucumber daily; they are both awesome and provide a similar end result. I enjoy writing Cucumber features but in certain circumstances it doesn't scale for large/complex applications (in my experience). I think that this isn't a problem for many people though, unless they're doing something wrong 'under the hood'.
