I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
Many programming methodologies are proposed these days, but the entire "field" smells of pseudo-science. Unless studies are done that can show statistically significant differences in relevant metrics (defect density, time required to add a feature, etc.), it's just a matter of opinion.
* Reaction A: code is ugly, what a bunch of jerks!
* Reaction B strikes me a bit as hero worship. Since we already know the outcomes, already some consider them geniuses; we must conclude every decision they made was a good one, and there is no room for criticism.
Perhaps neither are great, but I think reaction B especially is a little dangerous. One must acknowledge that there are more factors to your success than coding style, but that doesn't mean if you start neglecting it then it will also lead to your success.
How about the possibility that a1a is one of the people who just automatically equates "large volume of code" with "spaghetti"? In my experience there is a fair number of HN users (and devs in general) with this knee-jerk perspective.
In my very humble opinion any reasonable person who takes a few minutes to actually read through this code would never call it spaghetti. _Especially_ considering 1) the feature set of PHP at the time the code was leaked, 2) the immense scale of Facebook even at that time.
Like I posted - just below - a day before your post: "My post was not meant to trash the code, but rather to point out that this code shows us that the primary objective shouldn't necessarily be writing the perfect code."
That's a dangerous argument. I mean, if startups stopped pursuing the most elegant code, they wouldn't need, nor would they be able to hire, the "best" developers. And then what?
1. Lots of startups would be able to get off the ground and grow with less cash because they wouldn't have to pay six figures to every developer on staff.
2. It would be a lot easier to find acceptable candidates (no more "you have five minutes to implement sort on a whiteboard...to prove that you can build a web form" challenges during interviews).
3. There would be a lot less premature optimization and use of the framework or NoSQL database du jour.
4. Egos would be hurt as engineers with the most impressive educational backgrounds and deepest technical expertise would be forced to come to grips with the fact that, while they are valuable and have a big role to play at some companies, people with less formal training and knowledge can build working, commercially-viable CRUD applications.
This would be the end of the Silicon Valley startup world as it exists today, I tell you!
Shipped code > Well architected incomplete features.
Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.
Shipping quickly is important but it's also important to write quality code. Small bugs that can easily be fixed are fine but security problems or bugs related to payments, for example, are not.
These are not figures you want to see on your bottom line.
I think the unspoken secret here is the probability*loss for security issues is far less than the cost of missing features / delays.
I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests.
Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..
What are some other methodologies that can let me change code with the confidence well-written tests give me? Would love to be able to employ them when automated tests aren't feasible.
I always took this as an argument for smaller, composable components that value simplicity over complexity, dumb over smart and composable over monolithic. I personally (not quite there yet!) try to write code in this manner. I find that the more straight forward and simple the code, the less need there is for tests because I can hold the whole of the code base in my head.
Actually there is more wisdom hidden in this dogma. I'd argue you can't really well architect anything without iterating running code. So, it's more of a cycle. At least in my case. Proto, use, profile, refactor, proto new stuff into it, use, profile, refactor...
Sometimes (not always), it's best to release when ready. Shipping is important for a company, but for a dev team/individual it should be further down on the list and more importantly, development is not done after the first release and features don't maintain themselves.
I don't like the whole 'ship as soon as possible'-thing.
Shipping is a feature.
Someone recently mocked a full-stack-developer on HN as "I can javascript and servers too..". Oh man, how it made me cringe...In another 10 years, may be I won't have to. Off to dreaming...and coding...where is google....and stackoverflow of course...
We seem to be doing all right.
// TODO:
The best I've seen are (when reading DNA translated in all frames):
EVQLVE
LAMARCK
ELVISISGAY
SALTYSATAN
There is a whole world out there where people want to rely on software to do what it says it does. I know Facebook can live in its own bubble and get away with every possible stupid bug a messy PHP spaghetti causes.
Personally, I can't bring myself to not care like that, but it seems to have worked pretty well in the early days of many now-popular sites. Especially in 2007, when Facebook was still in real competition with MySpace, moving as quickly as possible was probably much more important than a few messages dropping through the cracks.
Also, when we say "important" in this context, is almost like asking "are you willing to pay for it?". Most people wouldn't pay a dime for ensuring the consistency of all their Facebook messages. So Facebook chose the right option.
My opinion is that you can have both performance and consistency, and work your way toward scalability as required. I recall that Facebook has a very high server-per-engineer ratio (though I acknowledge that the user-per-engineer ratio is even higher in comparison to other startups).
I also realize it is not cost-efficient to write bugfree software, but saying they did it the other way on purpose is forgiving them too much. You never write bad software intentionally.
They didn't care, and the world should have relied and should continue to rely on better software.