9gunpi

well, laying off the most expensive part of SC + focusing looks like business is getting mature and practical, given the competition and turning from 'exciting new thing' into regular normal business.

Well, folks it's mostly about calling syntax, as it is mentioned in the post, and it's more about ensuring that shooting in the foot is hard.

However, given the change of codebase size, there must be more changes in domains we're not interested in, like implementation of legacy primitives and infrastructure around them.

Indeed. But many broscience PhDs are quite big on creatine, I heard.

That intelligence-boosting powder that's the basis for super-findings of gym broscience?

This is very true, but Agile isn't the only un-achievable property in this case. Even basic healthy atmosphere and efficiency barely have a chance in these situations, so expecting someone in a wheelchair to run feels a bit naive.

Another kind of cult is religious adherence to methodology while ruining the very value the methodology is supposed to enhance.

When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation.

When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning.

All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.

Obviously there would be many web apps which would benefit from being end-to-end and not loose a lot in usability compared to non e2e ones

I feel WebCrypto (strange architectural choices made by people whose priorities are availability of crypto, not consistency of security) is even more questionable than running SJCL (a good crypto done by good people in questionable environment) in browser.

The problem is not only permissions. The problem is that code execution model within anything a mile close to web and browsers is a security threat by itself.

In some fields, incremental enhancement isn't enough, and that, I believe, is what killed Firefox phones. They've shown that their excellent engineering allows to run better code on cheaper spec - but people still buy phones for numbers in specs, not performance.

First class unsigned code in unsafe language support on a physical device seems to be a bit of a worrisome idea.

Explaining weird solutions with cute explanations is cute.

Having worked on SaaS products with high demands to security before, and having spent a serious chunk of people's hours on building security infrastructure around it, I'd say the biggest challenges were:

* Identifying threat model (assets we are protecting, what we are protecting them against), that connects to practical business values and risks, not abstract "security ideals". In our case it was understanding what kind of data we're afraid to lose / get tampered with to what extent - for some things we might've lost a license, for other things our CEO might've had a criminal case, so different measures applied.

* Orchestrating practical security with compliance (was relevant for that product, banking -> ISO, PCIDSS and local personal data protection regulation).

* Making hard decisions on whether doing it internally (we've had these competences) or outsourcing some of the implementation work to specialized outfit. Did it internally, was great experience, but would think twice to repeat.

* Making stakeholders understand how much the showstoppers, which emerge along the way, are important to be taken care of.

Git should have been written with pluggable hashes, right. Also, SHA1 could have been invented stronger against collisions in the first place.

In the retrospect many decisions which might have simplified current moment's problems are obvious, but in reality of those decisions in the past they never are. This feeling (it's called the retrospective predictability) is not a function of current problem or previous wrong decisions, but the random reality of events in complex systems, open source software implementing fresh ideas in a new way is being random and complex enough for this.

>If that's not the case, I don't see how they can make this claim.

Nobody knew it was even available?

Apple engineers are not different from the rest of people - deliver first, fix when fails. Wiping tombstones in constantly-syncing environment is a cumbersome piece of engineering.

The year people discover RDBMS are quick and reliable. Again.

Offsetting database layout decisions is not having better flexibility, it is having less clue about database layout, unfortunately.

Collecting data in some form and re/de-normalizing it in some useful fashion isn't exactly huge problem if you're not NetFlix or Google (and isn't huge problem even then).

It just requires certain amount of education.