Facebook’s Code Quality Problem
Graham King (via Dave DeLong, comments):
The Facebook iOS app has over 18,000 Objective-C classes, and in a single week 429 people contributing to it. That’s 429 people working, in some way, on the Facebook iOS app. Rather than take the obvious lesson that there are too many people working on this application, the presentation goes on to blame everything from git to Xcode for those 18,000 classes.
[…]
“These two data points seem to suggest that when Facebook employees are not actively making changes to infrastructure because they are busy with other things (weekends, holidays, or even performance reviews), the site experiences higher levels of reliability.”
The article moves on, without wondering whether releases regularly breaking your app are a normal part of the software engineering process.
David Reiss (via steffandroid):
That’s when we had the idea of using a JNI extension to replace the existing buffer with a larger one. At first, this idea seemed completely insane. Modifying the internals of the Java class loader is one thing, but modifying the internals of the Dalvik VM while it was running our code is incredibly dangerous. But as we pored over the code, analyzing all the uses of LinearAlloc, we began to realize that it should be safe as long as we did it at the start of our program. All we had to do was find the LinearAllocHdr object, lock it, and replace the buffer.
[…]
But for some reason it failed on the Samsung Galaxy S II… The most popular Gingerbread phone… Of all time…
[…]
Manual inspection of the GSII revealed that the LinearAlloc buffer was only 4 bytes from where we expected it, so we adjusted our code to look a few bytes to each side if it failed to find the LinearAlloc buffer in the expected location. This required us to parse our process’s memory map to ensure we didn’t make any invalid memory references (which would crash the app immediately) and also build some strong heuristics to make sure we would recognize the LinearAlloc buffer when we found it. As a last resort, we found a (mostly) safe way to scan the entire process heap to search for the buffer.
See also: Background Data and Battery Usage of Facebook’s iOS App, The Facebook App’s 18,000 Classes.
Update (2015-11-10): sippeangelo (via Laura Jane Watkins):
Whatever a OptimisticPayloadFactoryProtocol-protocol is, I don’t want to know…
Real Programmers can write java in any language.
5 Comments RSS · Twitter
There are two types of programmers in this world: the ones who invest time and effort in understanding the problem domain, and the ones who are only interested in writing code.
Needless to say, the latter should not be allowed anywhere near a keyboard as their largest contribution is to add negative value to the product. Though it's hardly surprising they should be endemic in corporate; coders who only know how to code being a perfect complement to managers who only know how to manage.
The phrase "fractally feculent" somehow springs to mind; I cannot imagine why.
@Lukas: Ah, but why write a simple, reliable, boring solution when you can have so much more fun creating a thrillingly complicated, convoluted, interesting problem to solve instead?
"There are two types of programmers in this world: the ones who invest time and effort in understanding the problem domain, and the ones who are only interested in writing code."
Actually, there are three types of programmers. The two types you mention, plus programmers who divide all programmers into two types. It's about ethics in categorizing programmers.
"Should have stuck to an HTML view in a native wrapper."
Speed, speed, speed. No?
@chucky
Correction: There are four type of programmers: good programmers, bad programmers, and programmers who make off-by-one errors.
