4 ms·

Good post and an interesting glimpse into the behind-the-scenes efforts that goes into maintaining Github. I cannot agree with the "Should I do it too?" sectio

Good post and an interesting glimpse into the behind-the-scenes efforts that goes into maintaining Github. I cannot agree with the "Should I do it too?" section. It probably works very well for an org as large and dedicated as Github, it very likely makes a lot of sense for what they do at the scale they do it at. For most of us that are consumers of technologies and frameworks, treating the framework as an extension of an application stack, as the blog has outlined, is a terrible idea; it requires devoting time and effort towards its upkeep, and that is not our core business, nor should it be. That does not, however, mean it's being treated as an unimportant part of the application stack, and implying so is judgmental. It's importance is that you need to be careful about the tech choices you make and understand what the implications will be down the line.

awesomegoat_com 4y ago
> it requires devoting time and effort towards its upkeep, and that is not our core business, nor should it be. I would try to argue that this in fact may be subjective. For me, updating all the dependencies in my stack every morning is a productivity routine that gets me started. If I spend a 30 minutes studying changelog of a dependency and linked github issues, I don't see that time as wasted even though it often does not contribute to the business. I think it has three benefits. - easy morning start routine to get going - developer education, expanding horizons - code climate; having warn feeling in the gut of not falling behind, wanting to avoid dirty plugs and monkey patches, ability to work on the HEAD, should an issue arise.
- ysavir 4y ago
  I think the parent comment is referring to the act of submitting code changes to Rails directly whenever behavior is needed. Staying up to date with what your dependencies are doing and why makes sense for any project, but actively contributing to the dependencies isn't necessarily a great investment when it doesn't benefit your bottom line in a direct and timely matter. Github has a large enough staff that it can dedicate time to open PRs to the Rails repo without giving up its own productivity, but if you're looking at a team of 10 developers, taking time away from your own product to improve Rails can be a significant time cost.
mkl95 4y ago
> For most of us that are consumers of technologies and frameworks, treating the framework as an extension of an application stack, as the blog has outlined, is a terrible idea My team currently does something similar albeit with a smaller framework (we are also much smaller than GH!), and it has done wonders for the stability of our flagship app. Imo it's only a terrible idea if your company does not want you to do it.
devjab 4y ago
I absolutely agree that it's very rare for a non-software engineering organisation to care one bit about its tech stack, at least outside of the IT departments. As long as things work reasonably well at a reasonable cost, the organisation will likely be happy about it. This is partly because IT (this includes software development) is seen as an expense center which provides a support function, akin to HR. Maybe some people will think this is silly, especially in companies where every employee spend all of their working time on some sort of digital device, but that's the reality that I have spent the past two decades working within, and I don't particularly mind it. I'm curious as to why you would disagree with what Adam Hess writes about handling updates though. To me he respectfully outlines that GitHub has engineering capabilities that allow them to update their Ruby on Rails weekly, and that it's a good idea to do so, if you can. I can follow you as far as how the application stack isn't the core business in the sort of organisations you and I seem to work for, and weekly updates likely shouldn't be your goal, but I do think that you should allocate the resources needed to keep things relatively up-to-date. I'll give you an example of how I don't follow my own advice. We have what has developed into an important asset management system that we build in-house, which due to a lack of updates being prioritized now cannot be build on the LTS version of it's core tech. This isn't a major problem today, because it's on an internal system on a virtual network which is heavily protected, but it's also gotten to the point where it will likely need one or two people to work full time for a week to a month to get it updated. Doing that might actually be cheaper than having kept it sort of up-to-date, maybe with quarterly or even yearly updates, but if we couldn't get those prioritized, how do you think we're going to get a week-month for updates prioritized? :p
- re-thc 4y ago
  > As long as things work reasonably well at a reasonable cost, the organisation will likely be happy about it. Or maybe the organization is just uninformed of the issues. Most management of organizations lack a view into 80% of the issues at hand. > some people will think this is silly It's sad rather than silly. Like when I go to a supermarket and can't checkout because the terminals are down... right it's not a core part of the business and just a cost center. So I decide to order online and their checkout form goes into an infinite loop and I give up... they've lost customers.
re-thc 4y ago
> and that is not our core business, nor should it be And that's problem. Tech is an integral part of most businesses now. Chances are if there's an outage you'll lose customers. It's a core part of your business - possibly 1 of the most important. Often the #1 reason why something can't be done is that the tech behind it doesn't support it.

awesomegoat_com 4y ago

> it requires devoting time and effort towards its upkeep, and that is not our core business, nor should it be. I would try to argue that this in fact may be subjective. For me, updating all the dependencies in my stack every morning is a productivity routine that gets me started. If I spend a 30 minutes studying changelog of a dependency and linked github issues, I don't see that time as wasted even though it often does not contribute to the business. I think it has three benefits. - easy morning start routine to get going - developer education, expanding horizons - code climate; having warn feeling in the gut of not falling behind, wanting to avoid dirty plugs and monkey patches, ability to work on the HEAD, should an issue arise.

ysavir 4y ago
I think the parent comment is referring to the act of submitting code changes to Rails directly whenever behavior is needed. Staying up to date with what your dependencies are doing and why makes sense for any project, but actively contributing to the dependencies isn't necessarily a great investment when it doesn't benefit your bottom line in a direct and timely matter. Github has a large enough staff that it can dedicate time to open PRs to the Rails repo without giving up its own productivity, but if you're looking at a team of 10 developers, taking time away from your own product to improve Rails can be a significant time cost.

mkl95 4y ago

> For most of us that are consumers of technologies and frameworks, treating the framework as an extension of an application stack, as the blog has outlined, is a terrible idea My team currently does something similar albeit with a smaller framework (we are also much smaller than GH!), and it has done wonders for the stability of our flagship app. Imo it's only a terrible idea if your company does not want you to do it.

devjab 4y ago

I absolutely agree that it's very rare for a non-software engineering organisation to care one bit about its tech stack, at least outside of the IT departments. As long as things work reasonably well at a reasonable cost, the organisation will likely be happy about it. This is partly because IT (this includes software development) is seen as an expense center which provides a support function, akin to HR. Maybe some people will think this is silly, especially in companies where every employee spend all of their working time on some sort of digital device, but that's the reality that I have spent the past two decades working within, and I don't particularly mind it. I'm curious as to why you would disagree with what Adam Hess writes about handling updates though. To me he respectfully outlines that GitHub has engineering capabilities that allow them to update their Ruby on Rails weekly, and that it's a good idea to do so, if you can. I can follow you as far as how the application stack isn't the core business in the sort of organisations you and I seem to work for, and weekly updates likely shouldn't be your goal, but I do think that you should allocate the resources needed to keep things relatively up-to-date. I'll give you an example of how I don't follow my own advice. We have what has developed into an important asset management system that we build in-house, which due to a lack of updates being prioritized now cannot be build on the LTS version of it's core tech. This isn't a major problem today, because it's on an internal system on a virtual network which is heavily protected, but it's also gotten to the point where it will likely need one or two people to work full time for a week to a month to get it updated. Doing that might actually be cheaper than having kept it sort of up-to-date, maybe with quarterly or even yearly updates, but if we couldn't get those prioritized, how do you think we're going to get a week-month for updates prioritized? :p

re-thc 4y ago
> As long as things work reasonably well at a reasonable cost, the organisation will likely be happy about it. Or maybe the organization is just uninformed of the issues. Most management of organizations lack a view into 80% of the issues at hand. > some people will think this is silly It's sad rather than silly. Like when I go to a supermarket and can't checkout because the terminals are down... right it's not a core part of the business and just a cost center. So I decide to order online and their checkout form goes into an infinite loop and I give up... they've lost customers.

re-thc 4y ago

> and that is not our core business, nor should it be And that's problem. Tech is an integral part of most businesses now. Chances are if there's an outage you'll lose customers. It's a core part of your business - possibly 1 of the most important. Often the #1 reason why something can't be done is that the tech behind it doesn't support it.