How we keep GitHub fast
github.com
github.com
Edit:
I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than 10 minutes of actual focus) and think to myself: "If that were me, I'd feel like I was just goofing off"
Get the information there. Make sure its nice and and usable. This does more than that though, which is great. I personally just would feel like I was wasting time and energy worrying about picking a color scheme when I had other work to be done.
Third thought: I appreciate the romantic justifications mentioned in the replies. I think they're fairly superficial, but they are romantic, and thats fine. I think the real difference here (and the root of the disagreement) has to do with why I associate this with 'waste of time'. There is obviously opportunity cost of doing this. I expect people most in favor of this stuff are salaried and not really concerned with opportunity cost. If I were salaried, I wouldn't feel like I was doing something wrong by doing this work because I'd do in in addition to my other work. I'd stay late and do it because I enjoyed doing it. I don't have that luxury where there isn't much opportunity cost because I'm paid by the hour. I don't work over-time. I'm not going to spend an extra hour at work one day to take care of this, so if its going to get done, its going to have to be prioritized over my other work. If picking colors (however important it is) is the most important thing on my to-do list, I have a problem.
TLDR: I'm paid by the hour. Thats probably why I feel this way.
Likewise, we've spent a ton of valuable time graphing and mining data from all over our stack; it's only natural that after that, we care about how we present that data. Like typography, it's hard because it's an arduous hunt for the aesthetics hidden behind information. But this hunt is what makes us human.
That's why we design beautiful graphs, just like we'd design a beautiful typeface. Not because we are GitHubbers, nor because we are designers, but because we are humans.
Life is too short to stare at ugly graphs. And yes, you should feel bad.
PS: we have no project managers at GitHub.
Just 'cause there's non-code aspects doesn't mean they have freedom to be ugly when you're striving for excellence.
edit: English fail.
As a developer I'm totally jealous of the ability to create simultaneously elegant and usable UI/UX, even when I used to try and just copy the CSS and structure right from the HTML source (I've since stopped) it was always missing that "je ne sais quois".
I think it's because, when it looks good, it's easier to find the information, and it makes you want to look at it. It makes you want to work with it.
Now then again while I realize github has a huge, huge amount of things running at the same time, I do find github quite a bit slower than my "own" remote repos :P
-Steve Jobs
"available with a solid domestic walnut top, sides and doors with a plywood bottom and low voc finish or painted mdf."
(Of course, these little details about what's "the right way to do it" are rather irrelevant to the greater point, which is that if you're the type to want to do things the right way, you're going to do things that way. Just don't hate on plywood, it has its uses (and feel free to come up with the programming equivalent!))
Edit -- some more notes on plywood: a sizable piece of plywood (like for the back of a chest of drawers or bookshelf) is going to be stronger (especially with regard to bending, IIRC) and vastly cheaper than a solid piece of wood since it only needs thin pieces of veneer with good grain for the outer layers. And IMO, it looks nicer than having several individual solid-wood boards jointed together in parallel.
We have some amazing antique Persian and Korean chests in the house. Hand carved and split grain matched fronts and maybe sides, but the backs are plain and/or rough hewn. These pre-date plywood, but the same goes - don't waste effort on parts that will never be seen, just build them to do their job.
It's "strong enough" and very light to ship. That's the only reason.
It's not strong enough for a lot of tasks and is definitely not good quality. One water spill and throw it away as the laminate just peels off - even on the expensive stuff.
I've taken to buying second hand good quality furniture (which is usually available at the same price as the shitty Ikea stuff) and stripping and painting it.
He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness."
In short, if there is a job worth doing, its worth doing well.
(Not to be too harsh, but I'm speaking from the experience of having been in the military and having spent years in the software industry.)
edit: for those that don't know, that jobs quote is in reference to why they put so much effort into their factories, which really were ridiculous.... jobs went on to just outsource everything after his return to apple
If Apple's products are quality all the way through, why can't I easily open up my iPod/iPhone/iPad?
If it's quality all the way through, why would you hide what's on the inside?
You can make an argument that they made the wrong trade-off between aesthetics and pragamatism, but for the trade-off they made, they executed well.
Your developers' efforts create enough value (once spread across millions of customers) that you have plenty of resources left over to take care of every little detail. And some of those details may include tools that make your developers' lives easier. There is great value in well-designed abstractions like GitHub's dashboard: the human brain can only hold so many details at once. When 2 dozen little details are organized onto an internal dashboard, your developers' brains can visualize them and load them into working memory in an instant, freeing them to work on harder problems more quickly and with less detail juggling. This is very freeing and relaxing, and can even help developers see possibilities they couldn't see before.
You can't justify tools like this for every $50K Rails-App-in-a-Box, but companies like GitHub and Google certainly can.
I think it would be a major management mistake to force (or even urge) someone like Kyle to do things half ass.
Thinking of your (team's) effort as a zero sum equation can get you in to trouble. Yes, you only have limited time and effort, but on the flip side, all the time you spend doing something, you're training. By building ugly things, you're training yourself to build... well... ugly things.
So I had to learn how to make beautiful plots. I used to be terrible at it, but one of my supervisors was very strict about plots: he would literally refuse to read reports in which plots weren't perfect (even draft reports). So I learnt how to make great plots (using ggplot2 for those who know R). At first, it took me forever to make any plot. Now, I can make very good ones in seconds.
So yes, instead of thinking of zero sum games, think of it as training.
If the data is available, making it 'pretty' is trivial.
http://twitter.github.com/bootstrap/
No need to waste your time, some people do....
No, but you should feel bad for thinking "it looks pretty" ==> "someone spent a lot of time making it look that way."
In particular, what you need to consider is: maybe they didn't spend all that much time on the visuals. Maybe they were either just really experienced, and it took next to no effort to get it to look that way... or maybe they had next to no knowledge, but used a framework to make it look as if they did.
I find this is a very common mistake managers make, BTW: assuming they can estimate, in the blink of an eye, how long it took to get a certain feature or behavior of an app into existence, out of nothing (and quite often, getting this estimate off by an order of magnitude in one direction or the other).
If this is (and it seems likely) an internal tool that gets used a lot, pretty soon the time it took to make it a little bit prettier/user-friendlier will be repaid in multiples during the entire lifespan of this application.
Really, prettier makes it easy to consume the information you want to, which is just as important as getting that info on the screen.
And I'm sure employees are happy if their admin interface is pleasant to look at and contributes to their productivity.
This is exactly the kind of opinion that perpetuates the mass of low quality crap in the world. It's an example of cutting corners, and long-term, it ends up costing so much more than it saves.
My goodness.
This is a small example of why that is true.
Toward that end, I'd say it's a fantastic use of resources.
- time spent thinking about what needs to be on the page (not extra)
- time spent thinking about what order the data should be displayed (not extra)
- time spent laying out the data (extra)
- time spent replacing the default font on the stylsheet (extra - minimal)
- time spent with getting graphs together (extra - but it is a skill. Once having done it, they could do this over and over)
Overall, I think the marginal time spent is well justified. Put it this way, your company probably hires cleaners to clean the office every day - that's a recurring cost. The cost sunk into a nicer design template gives the workers a nice working environment - that's significantly cheaper.
In my experience designing things nicely doesn't really cost more than designing it badly. In both cases "design" is being done - it's just that in once case you have an expert involved.
I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product.
I really enjoyed this post, and it keeps me ever inspired to thrive for good design: Nn code and in graphics. On the backend and on the frontend.
It's easy to go overboard with making something pretty when it's in-house, but at the same time I genuinely find that I'm more productive when using pretty software. It's probably the INFP in me, but when something is slightly off I find it incredibly distracting.
In the case of the github dashboard images in this blog post, they do look a little designed but nothing that would take an experienced interface designer more than an hour or so. Time well spent if it makes the idealists in your team happier.
"Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.
In the long run, market-based quality costs more. The lesson here is,
Quality, far beyond that required by the end user, is a means to higher productivity."
Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.
At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.
* It may well have taken substantially less time than you think. Once an organisation has a structure in place for how the UX of a web app should run, and infrastructure in place for making sure things are coded up to that standard (standard templates, test suites, process, etc.) then these things can go together very quickly. I don't know how github runs it's UX/design side - but they seem like the sort of folk who'd streamline the heck out of the process.
* Wearing my UX hat - most of what you see isn't hard. It's basically having decent typography choices, decent vertical rhythm, good visual hierarchy. The icons look off-the-shelf from somewhere. This stuff doesn't actually cost any more time to do right the first time if you already know what you're doing (just like good DBAs automatically write normalised schema).
* With something like this - which is a mode switch between the "nice" stuff that your customers see and the stuff that you see as a developer - it's easier to keep everything nice rather than make the context-switch in development between nice/nasty.
* Wearing my ux-speaking-to-developers hat - think of it like technical debt. Yeah - maybe you could throw something together quickly that would do the job. But if you leave it in it has a knock on effect with everything you do next. It makes tweaking and extending stuff in the future more difficult. Keeping the UI clean, like keeping the code clean, may cost a little more up-front but will save you time in anything but the short term.
* Good UIs are more effective. Making the tools that the internal folk use to make the site better more effective seems like a good choice to be making.
I don't make products for me. I make them for my audience. The right question to ask isn't, "Do I care about how pretty this is?" It's, "What do my users care about?"
Consumer-focused products (and Github is certainly one of them) require much more investment in visual and interaction design than, say, in-house software. It's how many people judge quality, and having a pleasant experience matters to a substantial chunk of the audience. Github has absolutely made the right choice in keeping their interface a pleasure to work with.
Just 2 performance concerns I've noticed:
1. The network graph https://github.com/<username>/<repo>/network seems very sluggish to render
2. The API is slower than normal for HTTPS
Usage: $> time curl -i https://<site>/ For comparison (2nd request's):
* https://www.googleapis.com/ 187ms
* https://graph.facebook.com/ 175ms
* https://api.github.com/ 400-700ms
Not sure if anyone else noticed this
(by the way, RSA labs deprecated the use of 1024 bit keys in 2003(!), so one could say that googleapis and fb use snake oil rather than ssl ...)
Didn't realize Github were using 2048 bit keys. I would be interested in knowing what the actual performance differences are between key sizes, given RSA is used in the initial negotiation before symmetric SSL takes over.
>so one could say that googleapis and fb use snake oil rather than ssl ...)
Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might be a stretch. ;)
sign verify sign/s verify/s
rsa 512 bits 0.000217s 0.000014s 4608.1 72363.4
rsa 1024 bits 0.000711s 0.000032s 1406.0 30788.2
rsa 2048 bits 0.003630s 0.000092s 275.5 10825.0
rsa 4096 bits 0.021180s 0.000299s 47.2 3349.2
Second, it has nothing to do with the "performance on your end" (the client).
The client side of SSL is limited to public key operations only (cert verification, encrypted the pre-master secret). These are 40x faster than private key ops, key length being constant. You're talking a difference of 60 microseconds on the client.
http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...
It also is (or used to be) possible for a particular graph to get into a wedged state; github support can fix that if you report the repo, but it's often not worth the effort for me.
- What does the top chart represent that blends into the background?
- What is so costly about rendering pages for Googlebot that it takes almost twice as long as the average rendering time for public views? The throughput is especially interesting as it is less than 30% of its public equivalent.
- What does 1 cpu unit equal to?
- Also interesting to me is the fact that API requests require the most horsepower, yet also provide almost the lowest response time and very high throughput. How API requests are so different from "browser" requests, since I suspect both are powered by the same backend?
Sorry for my naivety.
Googlebot tends toward the opposite of the pages we optimize for. For example, Googlebot is really interested in the 38,291th page of your history.
I think 1 CPU unit is a core, but I'm not sure. It's mostly interesting in terms of relative numbers.
And yes, both api and the web live in the same application servers.
I still don't grasp how API can be so efficient while doing basically the same thing as the public-facing site minus probably the HTML rendering, which leads me to believe that rendering is damn resource-heavy in Rails.
Chrome is reporting the code tab is taking 3.7 seconds to load. 22 HTTP requests. The Pull tab has over 100 HTTP requests. I don't consider anything over 1s to be fast.
Even the initial HTML is taking more than 1.5 seconds on the Pull tab! I think you should aim for 200ms for the HTML, and maybe 1s total. This is many times slower.
Amazon is pretty decent. Their full page loads are slow, but they concentrate on above-the-fold time which is OK. I don't use Facebook much, but I think they have pretty good latency.
I think Microsoft's new mail is pretty fast but I haven't used it much.
I would say 1.x seconds for initial HTML is average. And 3-4 seconds for the full page with all assets is average. Github is in the 3-4 seconds range for onload time.
So Github is not particularly bad -- it's just average. It's certainly not "fast".
I feel like Github's perceived latency is pretty bad. I think they end up showing spinners and redrawing various parts of page to try to hide latency, but it makes it seem janky to me.
A significant cause of the issue is their SSL implementation. Specifically it negotiates a new connection every time instead of resuming the session, eek!
http://security.stackexchange.com/questions/5511/ssl-session...
https://www.ssllabs.com/ssltest/analyze.html?d=github%2ecom&...
http://wiki.nginx.org/HttpSslModule
As for Github, could just be a misconfiguration, or perhaps they had some more deliberate reason in mind.
Good news is I just received confirmation from one of the ops guys. He says they know about it, and are working on a fix. :)
Any idea why the default in nginx is: none. Soft off: nginx says to a client that session can be resued, but nginx actually never reuses them. Seems like a bad default to not cache.
Bitbucket on the other hand is insanely slow, especially in the source browser. That said, I gladly tolerate it due to unlimited free private repos and a decent feature set.
Github are absolutely killing it right now.
"The simple act of putting a render time in the upper right hand corner of every page we serve forced us to fix all our performance regressions and omissions. [...]
Most of the performance fixes were trivial, and even the ones that were not turned into fantastic opportunities to rearchitect and make things simpler and faster for all of our users."
Stackexchange open sourced their profiler at http://miniprofiler.com/ (.NET & Ruby)
The post provides some data showing how they improved their site performance over time where Github just states they have a strategy to use "powerful internal tools that expose and explain performance metrics". Guess it's just common sense now.
Edit:
I was thinking of FiveRuns Tune-Up toolbar.
http://techcrunch.com/2008/05/29/dont-debug-alone-with-fiver...
It seems to be there (but not updated):
- Public repo search.
- Main search box says "Search or Type a Command"
- Heartbeat icon in main navigation.
- Compass icon in top right user navigation.
- Advanced search button is now an actual button."Responsive design", OTOH, is about a page that adapats to the user's screen resolution; eg: renders differently on 480x320 vs 1024x768, on the same code base. HTH.