|>>|| No. 22928
>You can't make excuses for it, you simply can't
I can. Software development is ridiculously, ludicrously hard. As a non-developer, you simply cannot comprehend the level of effort involved in making modern software work.
I know guys who work for Facebook and Google. They are unquestionably amongst the best of the best. Interviews at those companies take days, not hours. They are cherry-picking from the best graduates at MIT and Cambridge. A substantial number of the people working for those companies have turned down job offers from banks and intelligence agencies.
The current codebase for Chrome exceeds eight million lines of code. Eight million lines of tightly written, well documented, fully tested, ruthlessly refactored code. Facebook are managing a codebase that exceeds 62 million lines of front end code and four million lines of code just for the Android app. Even with the best people, they're barely hanging on by their fingernails to the immense scope of their software. Have you any idea what four million lines of anything looks like?
I'm a good developer - not great, I'll freely admit to that, but certainly in the top 10% of the field. I write open source libraries for fun and have a strong mathematical background. I have spent entire days chasing down bugs in a ten-line function and so have all of my peers. On a good day, I can audit one or two hundred lines of good quality code. Think about that in the context of multi-million line codebases. The browser you're using to read this has more human effort invested in it than the pyramids of Giza.
Huge security vulnerabilities in important products can be caused by the most trivial of errors or omissions. Heartbleed was caused by a single incorrect bounds check - essentially just four incorrect bytes. The Debian OpenSSL bug was caused by a single change made by a single developer to an apparently insignificant line of code. The foremost priority in any big shop is avoiding those kinds of fuckups, which involves a huge development and testing burden.
Software is just applied mathematics, so it is possible to formally verify software as a mathematical proof. This verification does take place for a tiny minority of ultra-important code (mainly military systems) but the cost of this is on the order of thousands of pounds per line. In most software, all we can do is follow best practices, test for the most important cases and hope that when things do break, they don't end up as headline news.
Nothing is simple in modern software. We're dealing with phenomenally complex systems, built upon layers and layers of legacy infrastructure. Once something becomes a standard, we're essentially stuck with it indefinitely for reasons of backwards compatibility. The ARM processor in your phone includes the same basic instruction set that was designed by Steve Furber and Sophie Wilson in 1985. The assets you downloaded to view this page include jQuery functions to work around bugs in Internet Explorer 6, a browser that has been obsolete for over a decade.
As developers, we aren't finding a needle in a haystack. We're solving a pile of rubiks cubes blindfolded in a giant pile of shit and broken glass. We're dealing with software that is immeasurably more complex than any individual could understand, even on a relatively high level. A trivial error by any of us could bankrupt a company overnight. We're totally reliant on code developed by other people, code that we often don't have full access to and couldn't audit in a hundred lifetimes anyway. We're burdened by the need to work with archaic standards, and constantly treading on landmines laid decades ago, often by brilliant developers who just lacked the right tools or had a project slip out of their control.
Due mainly to historical accident, a minor part of Netscape Navigator became one of the three most important programming languages in the world. Now we're stuck with it warts and all, because removing the most brain-dead bits would break millions of websites. Reforming it will take decades of hard work and politicking, so we have no choice but to write huge quantities of important code in a language that is badly broken. Thousands of developers spend a large part of their working day dealing with the consequences of mistakes made by one man in 1995.
This is what writing real software feels like: